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ABSTRACT 


This  thesis  describes  a  methodology  used  to  develop  a  systems  engineering  (SE) 
competency  framework  for  Space  and  Naval  Warfare  Systems  Center  (SSC)  Atlantic — a 
Department  of  Navy  organization  whose  vision  statement  is  to  “Make  IT  count  for  the 
Warfighter  and  the  Nation.”  This  methodology  defines  the  role  of  systems  engineers  at 
SSC  Atlantic;  establishes  prioritized  SE  competency  areas;  identifies  associated 
knowledge,  skills  and  abilities  (KSAs);  identifies  optimal  workforce  development 
methods  for  each  KSA;  and  addresses  how  to  assess  systems  engineers  against  a 
competency  development  model. 

The  results  of  this  analysis  show  that  systems  engineers  require  many  of  the  same 
KSAs  as  other  members  of  the  engineering  workforce,  but  also  require  unique  KSAs 
focused  on  customer  mission/capability  areas,  technology  areas,  SE  processes/activities 
and  leadership  skills.  Developmental  methods  for  systems  engineers  to  obtain  these 
KSAs  range  from  informal  on-the-job  training  to  professional  certifications  and  degrees. 
The  methodology  established  in  this  thesis  can  be  used  by  other  organizations  to  develop 
and  employ  their  own  competency  framework  in  practically  any  discipline.  The  SE 
competency  framework  defined  in  this  thesis  can  be  leveraged/tailored  by  other  SE 
organizations  in  order  to  establish  developmental  roadmaps  for  improving  the  KSAs  of 
their  workforce. 
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EXECUTIVE  SUMMARY 


This  thesis  examines  how  to  build  and  employ  a  framework  for  developing  the 
competency  of  systems  engineers  at  a  Department  of  Defense  (DoD)  organization  such  as 
Space  and  Naval  Warfare  Systems  Center  (SSC)  Atlantic.  While  there  are  many  high- 
level  government  and  industry  models  for  systems  engineering  (SE)  competency 
development,  few  provide  a  comprehensive,  prioritized  set  of  knowledge,  skills  and 
abilities  (KSAs),  recommendations  on  how  to  actually  develop  systems  engineers  and 
insight  into  how  systems  engineering  competency  might  be  assessed.  Furthermore,  there 
is  little  understanding  of  the  various  types  of  systems  engineers  at  an  information 
technology-centric  DoD  organization  and  how  their  skillsets  may  need  to  differ.  This 
thesis  examines  the  various  types  of  systems  engineering  competency  areas  and 
associated  KSAs  defined  by  Defense  Acquisition  University  (DAU),  National 
Aeronautics  and  Space  Administration,  International  Council  on  Systems  Engineering 
and  Naval  systems  engineering  competency  models.  It  also  examines  those  competency 
and  KSA  areas  that  are  of  particular  importance  to  SSC  Atlantic,  such  as  those  defined  by 
the  National  Institute  of  Standards  and  Technology  in  the  National  Cybersecurity 
Workforce  Framework.  This  paper  analyzes  various  forms  of  education  and  training  that 
can  be  used  to  support  the  development  of  systems  engineering  KSAs  and  when  they  are 
most  appropriate. 

The  results  of  this  thesis  show  that,  in  order  to  properly  develop  a  SE  workforce 

in  an  IT  command  such  as  SSC  Atlantic,  one  must  first  understand  what  competency 

areas  and  KSAs  systems  engineers  must  attain.  A  SE  competency  framework  should 

consider  the  SE  life  cycle  processes,  and  also  technology  areas,  mission/capability  areas 

and  leadership  skills  to  ensure  that  systems  engineers  are  well  rounded  in  order  to  provide 

technical  leadership  to  multi-disciplinary  teams  with  role-diverse  team  members.  When 

establishing  a  competency  framework,  careful  consideration  should  be  made  toward 

which  precise  use  case(s)  will  be  supported  by  the  framework.  Identifying  relevant  and 

authoritative  competency  area  and  KSA  sources  for  the  competency  framework  is  also 

critical,  as  there  is  no  need  to  recreate  data  that  has  already  been  adequately  developed  by 

xvii 


several  other  relevant  and  established  industry  and  DoD  organizations.  When  prioritizing 
competency  areas  and  KSAs,  each  SE  use  case  must  be  considered  separately  as  each 
will  likely  emphasize  different  competency  areas.  Competency  areas  such  as  stakeholder 
requirements  definition,  requirements  analysis,  architecture  design,  software  engineering, 
acquisition,  verification  and  system  assurance  require  more  emphasis  at  SSC  Atlantic 
than  others.  In  order  to  establish  systems  engineering  roles  that  can  be  well  understood 
across  the  organization,  one  must  examine  the  roles  that  will  interact  with  the  role  of  a 
systems  engineer  in  order  to  determine  where  KSAs  will  be  shared  across  the  roles  or 
unique  to  one  or  the  other. 

Analysis  must  also  be  conducted  to  understand  how  these  KSAs  can  and  should 
be  obtained.  The  most  common  methods  for  developing  SE  KSAs  are  through 
educational  training  (DAU,  degrees  or  certifications),  in-house-developed  training 
courses/workshops,  and  on-the-job  training  (OJT).  DAU  Systems  Planning,  Research, 
Development  &  Engineering — SE  classes  can  be  effective  when  providing  systems 
engineers  with  basic  knowledge  and  comprehension  of  the  SE  life  cycle  processes — 
particularly  in  the  areas  of  acquisition  and  risk  management.  Leadership  skills  can  be 
developed  through  programs,  such  as  the  Mid-Career  Leadership  and  Mentorship 
Programs.  OJT  can  be  enhanced  when  coupled  with  targeted  rotational  and  job 
shadowing  opportunities.  If  approached  systematically,  immeasurable  value  can  be 
obtained  from  developing  in-house  SE  training  that  engages  systems  engineers  at  all 
levels  of  the  workforce.  The  Graduate  Reference  Curriculum  for  Systems  Engineering 
provides  useful,  tailorable  recommendations  on  how  to  develop  and  assess  SE  curricula. 
When  it  comes  to  assessing  the  competency  of  systems  engineers,  care  must  be  taken  to 
choose  an  assessment  process  and  associated  assessment  methodologies  that  are 
relatively  thorough  yet  not  overly  cumbersome,  time-consuming  and  costly. 

This  thesis  goes  through  the  process  of  establishing  a  SE  competency  framework 
for  SSC  Atlantic  that  can  easily  be  tailored  for  other  SE-focused  organizations.  The 
process  begins  by  defining  the  role(s)  of  systems  engineers  within  the  organization.  Then 
existing  competency  frameworks  are  examined  in  order  leverage  existing  best  practices. 


Competency  areas  (or  KSA  groupings)  are  examined  and  prioritized  based  on  how 
systems  engineering  should  be  conducted  in  the  most  likely  project  use  cases. 

Once  the  basic  requirements  for  the  competency  framework  are  established,  then 
a  competency  framework  is  built  to  address  a  complete  set  of  competency  areas  and 
KSAs  desired  for  systems  engineers  within  an  organization.  Alternative  methods  are 
defined  for  developing  competency.  Criteria  are  established  to  determine  optimal 
methods  for  developing  different  types  of  KSAs.  This  allows  for  each  systems  engineer 
KSA  to  be  mapped  to  optimal  development  methods.  Finally,  a  manner  for  assessing 
systems  engineers  is  developed  and  executed  in  order  to  track  each  systems  engineer’s 
progression  in  terms  of  proficiency. 
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I. 


INTRODUCTION 


A.  BACKGROUND 

Since  the  inception  of  the  field  of  systems  engineering,  corporations  and 
government  organizations  worldwide  have  been  trying  to  figure  out  what  knowledge, 
skills  and  abilities  (KSAs)  are  most  crucial  for  practicing  systems  engineers. 
Competency  models,  such  as  the  systems  planning,  research,  development  and 
engineering — systems  engineering/program  systems  engineering  (SPRDE-SE/PSE) 
competency  model  developed  by  Defense  Acquisition  University  (DAU)  and  the  project 
management  and  systems  engineering  competency  framework  developed  by  the  National 
Aeronautics  and  Space  Administration  (NASA)  help  frame  what  KSAs  are  most  needed 
in  order  to  effectively  perform  systems  engineering  (see  NASA,  2012  and  DAU  SPRDE- 
SE/PSE  Competency  Model,  2009).  As  the  systems  being  engineered  continue  to  evolve 
and  become  more  complex,  some  competency  models,  such  as  the  International  Council 
on  Systems  Engineering  (INCOSE)  systems  engineering  competency  framework  have 
also  evolved  in  order  to  address  system  complexity  throughout  the  systems  engineering 
life  cycle  (International  Council  on  Systems  Engineering  [INCOSE],  2010). 

Today  the  challenge  does  not  lie  as  much  in  developing  or  adopting  a  competency 
model  for  an  organization  tasked  with  delivering  complex  systems,  as  there  are  many 
overarching  and  industry-standard  models  from  which  to  choose.  Rather,  the  greater 
challenge  is  figuring  out  how  to  tailor  and  employ  existing  competency  models  in  order 
to  develop  individuals’  KSAs  in  an  effective  and  cost-efficient  manner.  In  other  words, 
how  do  we  know  which  competency  areas  and  KSAs  are  most  critically  needed  to 
perform  systems  engineering?  What  are  the  variables  in  systems  engineering  that  drive 
the  importance  of  the  various  systems  engineering  (SE)  competency  areas?  What 
methods  should  be  employed  to  develop  KSAs  in  systems  engineers — on-the-job  training 
(OJT),  in-house  classroom  training,  vendor-provided  training,  undergraduate  or  graduate 
programs,  etc.?  Under  what  circumstances  is  each  method  most  appropriate? 
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B.  PURPOSE 


The  purpose  of  this  thesis  is  to  understand  what  type  of  competency  framework 
Space  and  Naval  Warfare  Systems  Center  (SSC)  Atlantic  should  employ  in  order  to 
develop  its  systems  engineers.  This  will  be  achieved  by  synthesizing  together  elements 
from  industry  and  government-standard  competency  models  that  have  been  generated  by 
organizations  external  to  SSC  Atlantic.  This  will  also  include  drawing  from  legacy 
competency  models  employed  by  SSC  Atlantic  over  the  last  five  years.  This  thesis  aims 
to  determine  what  types  of  education  and  training  (structured  and  unstructured)  can  best 
be  used  to  maximize  the  effectiveness  of  systems  engineers. 

More  specifically,  this  thesis  will  examine  various  types  of  systems  engineering 
competency  areas  and  associated  KSAs  defined  by  DAU,  NASA,  and  INCOSE 
competency  models.  This  thesis  will  also  look  closely  at  the  Naval  Systems  Engineering 
(SE)  Competency  Development  Model  (CDM),  which  itself  is  tailored  from  a  strong 
pedigree  of  various  organizations’  SE  competency  frameworks — those  of  NASA,  DAU 
and  INCOSE,  but  also  of  Boeing  and  the  Naval  Underwater  Warfare  Center,  Newport. 
This  thesis  will  also  examine  those  competency  and  KSA  areas  that  are  of  particular 
importance  to  SSC  Atlantic,  such  as  those  defined  by  the  National  Institute  of  Standards 
and  Technology  (NIST)  in  the  national  cybersecurity  workforce  framework  (NCWF). 
The  Graduate  Reference  Curriculum  for  Systems  Engineering  (GRCSE)  will  also  be 
examined  to  determine  how  it  can  be  applied  in  order  to  employ  a  newly-tailored  SSC 
Atlantic  SE  CDM. 

C.  RESEARCH  QUESTIONS 

1 .  What  competency  areas  and  associated  KSAs  are  particularly  applicable  to 
SSC  Atlantic  systems  engineers? 

2.  How  can  the  GRCSE  be  used  to  effectively  employ  a  CDM? 

3.  How  do  various  forms  of  education  and  training  best  support  the 
development  of  KSAs  required  to  develop  competent  systems  engineers  at 
SSC  Atlantic? 
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D.  BENEFITS  OF  STUDY 


This  thesis  is  intended  to  provide  recommendations  to  the  leadership  of 
Department  of  Defense  (DoD)  IT  organizations  on  how  to  best  approach  competency 
development  and  the  delivery  of  systems  engineering  education,  training  and  other  forms 
of  developmental  opportunities  to  their  engineering  workforce.  More  specifically,  the 
Space  and  Naval  Warfare  Command  (SPAWAR)  and  its  systems  centers — SSC  Atlantic 
and  SSC  Pacific — as  well  as  similar  organizations  should  benefit  from  these  analyses  and 
recommendations.  These  recommendations  will  be  used  to  shape  future  SE  course 
learning  objectives  and  competency  development  models  employed  by  SPAWAR.  The 
recommendations  should  assist  in  making  better  decisions  on  where  to  spend  workforce 
development  training  funds  in  an  increasingly  budget-constrained  DoD  environment. 
This  thesis  will  also  provide  an  approach  toward  tailoring  and  employing  competency 
development  models  for  a  DoD  organization  whose  primary  mission  is  to  deliver 
complex  IT  solutions  to  a  diverse  base  of  end  users. 

E.  SCOPE  AND  METHODOLOGY 

This  thesis  seeks  to  develop  a  competency  framework  that  can  be  directly  used  by 
SSC  Atlantic  to  develop  various  types  of  systems  engineers.  This  framework  defines 
how  CDMs  are  structured  and  employed  in  terms  such  as  competency  vectors  and 
competency  areas.  Each  individual  CDM  within  the  framework  is  based  upon  different 
systems  engineering  use  cases  and  will  define  the  associated  KSAs  categorized  by 
competency  stages,  or  levels.  The  methodology  depicted  in  Figure  1  is  employed  in 
order  to  develop  this  overarching  SE  competency  framework. 
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Step  1:  Define  the  role($)  of  systems 

Step  7:  Develop  and  assess 

engineers  at  SSC  Atlantic 

systems  engineers 

Step  2:  Identify  existing  competency  model 
frameworks  relevant  to  SSC  Atlantic 


Step  3:  Identify  and  prioritize  competency 
areas  and  KSAs  that  are  applicable  to  SSC 
Atlantic 


Step  6:  Map  KSAs  to  optimal 
workforce  development 
methods 

_ : _ 

Step  5:  Identify  alternative 
methods  for  developing  KSAs 


Step  4:  Design  and  build  a  tailored 
competency  framework  that 
addresses  a  complete  set  of 
competency  areas  and  KSAs  desired 
for  systems  engineers 


Figure  1.  SE  Competency  Framework  Development  Methodology 


Figure  1  depicts  the  seven-step  process  applied  throughout  Chapters  II  through  IV 
of  this  thesis  in  order  to  establish  the  proposed  SSC  Atlantic  SE  competency  framework. 
The  following  section  summarizes  each  of  these  steps. 

1.  Define  the  Role(s)  of  Systems  Engineers  at  SSC  Atlantic 

In  order  to  understand  the  role  of  a  systems  engineer,  first  the  purpose  of  systems 
engineering  will  be  examined,  as  well  as  the  secondary  disciplines  or  fields  of  study 
related  to  systems  engineering  that  are  frequently  applied  at  SSC  Atlantic.  Next,  the 
general  role  of  an  SSC  Atlantic  systems  engineer  will  be  defined,  along  with  the  different 
types  of  systems  engineer  roles,  defined  herein  as  “subroles.” 

2.  Identify  Existing  Competency  Model  Frameworks 

Identifying  existing  SE  competency  frameworks  will  require  exploration  into 
models  currently  used  by  organizations  such  as  NASA,  DAU,  INCOSE  and,  most 
importantly,  the  Department  of  Navy  and  U.S.  Marine  Corps.  There  are  also  a  number  of 
fields  of  study  that  overlap  with  systems  engineering.  For  example,  project  management, 
enterprise  architecture  and  IT  service  management  are  all  fields  of  practice  that  share 
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common  process  areas  and  correlated  life  cycle  models  with  systems  engineering. 
Because  SSC  Atlantic’s  mission  within  the  DON  focuses  on  delivering  information 
technology  (IT)  solutions,  the  national  cybersecurity  workforce  framework  (NCWF) 
developed  by  NIST  proves  to  be  particularly  relevant  to  the  cause  (National  Initiative  for 
Cybersecurity  Education,  2013).  There  are  also  a  number  of  leadership  competencies  and 
personal  attributes,  typically  called  soft  skills  or  professional  skills,  such  as  verbal 
communication,  conflict  resolution  and  strategic  thinking  that  enhance  the  proficiency 
and  development  of  systems  engineers.  Exploring  the  KSAs  associated  with  each  of 
these  fields  can  ultimately  add  value  to  the  competency  framework  for  a  systems 
engineer. 


3.  Identify  and  Prioritize  Competency  Areas  and  KSAs  that  are 
Applicable  to  SSC  Atlantic 

Existing  competency  model  frameworks  for  SE  and  related  fields  all  come 
equipped  with  some  mechanism  with  which  to  categorize  KSAs.  These  categories, 
known  as  competency  areas,  each  supply  KSAs  that  are  tailored  at  various  competency 
level  stages,  which  are  defined  in  this  study  as  entry,  intermediate,  advanced  and  expert. 
This  step  of  the  methodology  first  examines  which  competency  areas  from  the 
frameworks  identified  in  Steps  2  and  3  are  most  applicable  to  SSC  Atlantic. 
Furthermore,  specific  KSAs  from  these  competency  areas  are  selected  for  inclusion  into 
the  SSC  Atlantic  competency  development  model.  This  step  also  involves  prioritizing 
which  competency  areas  and  specific  KSAs  are  most  relevant  to  the  role  of  an  SSC 
Atlantic  systems  engineer. 

4.  Design  and  Build  a  Tailored  Competency  Framework  That  Addresses 
a  Complete  Set  of  Competency  Areas  and  KSAs  Desired  for  Systems 
Engineers 

Once  a  complete  set  of  prioritized  competency  areas  and  KSAs  have  been  defined 
for  the  SSC  Atlantic  systems  engineer,  a  new  competency  framework  must  be  established 
which  organizes  competency  areas  and  KSAs  into  high  level  competency  vectors. 
Organizing  this  new  competency  framework  into  competency  vectors  will  assist 
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engineering  managers  in  communicating  the  general  contents  of  the  SSC  Atlantic  SE 
competency  framework. 

5.  Identify  Alternative  Methods  for  Developing  KSAs 

Once  a  complete  list  of  applicable  competency  areas  and  KSAs  has  been 
developed  for  SSC  Atlantic  systems  engineers,  the  process  for  determining  how 
individuals  best  develop  these  KSAs  can  begin.  Basic  methods  for  developing  KSAs 
include  OJT,  educational  training  (degree  and  certification  programs)  and  professional 
development. 

6.  Map  KSAs  to  Optimal  Workforce  Development  Methods 

In  order  to  determine  the  optimal  development  methods  for  systems  engineering 
KSAs,  decision  criteria  will  be  established.  Using  these  decision  criteria,  each  KSA  in 
the  newly  established  SSC  Atlantic  SE  competency  framework  will  be  mapped  to  its 
optimal  development  method(s). 

7.  Develop  and  Assess  Systems  Engineers 

This  step  will  leverage  the  SE  competency  framework  established  in  Steps  1 
through  6  in  order  to  develop  SSC  Atlantic  systems  engineers  through  the  entry, 
intermediate,  advanced  and  expert  stages  of  the  CDMs  most  applicable  to  their  SE 
subroles.  This  step  will  also  provide  a  high  level  overview  for  how  to  assess  systems 
engineers  (or  any  other  role)  against  the  associated  CDM  stages. 

F.  THESIS  ORGANIZATION 

This  thesis  is  organized  by  chapters  covering  the  following  topics: 

1.  Chapter  I:  Introduction — describes  the  thesis  background,  purpose,  the 
questions  to  be  answered,  projected  benefits,  methodology  and  content 
organization. 

2.  Chapter  II:  Problem  Definition — This  chapter  summarizes  the  relevant 
research  on  the  problem,  defines  the  problem  statement  and  provides 
context  for  the  thesis.  More  specifically,  this  chapter  defines  the  role  of 
systems  engineers  at  SSC  Atlantic  (Step  1),  defines  key  terms  associated 
with  competency  models  and  identifies  competency  models  relevant  to  SE 
at  SSC  Atlantic  (Step  2). 
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3.  Chapter  III:  Applying  SE  Competency  Areas  to  SSC  Atlantic:  This 
chapter  discusses  how  KSA  data  is  used  at  SSC  Atlantic.  This  chapter 
also  examines  which  competency  areas  and  KSAs  described  in  existing 
competency  frameworks  are  most  germane  to  how  SSC  Atlantic  engages 
in  systems  engineering  (Step  3). 

4.  Chapter  IV :  Designing  a  New  Competency  Framework  for  SSC  Atlantic 
SE  Roles  and  Subroles — This  chapter  establishes  a  new  framework  for  SE 
competency  development  equipped  with  competency  vectors  relevant  to 
the  SSC  Atlantic  mission  (Step  4).  This  chapter  defines  SSC  Atlantic 
roles,  subroles  and  their  associated  use  cases. 

5.  Chapter  V:  A  Model  for  Effective  Systems  Engineering  Workforce 
Development  at  SSC  Atlantic — This  chapter  discusses  how  the  SSC 
Atlantic  competency  framework  can  be  employed  using  alternative 
methods  for  employee  development  of  KSAs  (Step  5).  This  chapter 
describes  each  workforce  development  method  and  provides 
recommendations  on  where  each  is  most  appropriate  for  developing 
systems  engineering  KSAs  (Steps  6  and  7).  The  chapter  concludes  with 
an  overview  for  how  to  assess  competency  or  proficiency  levels  against  a 
CDM. 

6.  Chapter  VI:  Conclusions  and  Recommendations — This  chapter 
summarizes  the  research,  reiterates  the  key  findings,  and  recommends 
areas  for  future  research. 
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II.  PROBLEM  DEFINITION 


A.  SYSTEMS  ENGINEERING— THE  CORE  ELEMENTS 

Since  its  formal  beginning  in  the  mid-twentieth  century,  systems  engineering  has 
been  defined  and  redefined  several  times.  In  1960,  Flagle,  Huggins  and  Roy  stated  that 
systems  engineers  “engage  in  the  analysis  of  complex  man  and  machine  systems  or  one 
may  also  say  man  and  machine  operations,  utilize  multi-discipline  teams,  employ  the 
scientific  method,  emphasize  the  ‘whole  system’  rather  than  the  component  approach”  (p. 
23).  This  early  definition  wonderfully  captures  several  of  the  key  facets  of  systems 
engineering.  The  first  key  element  of  this  definition  is  the  concept  that  the  human  is 
actually  part  of  the  system  and  that  systems  are  complex.  The  second  point  these 
pioneers  make  is  that  systems  engineering  requires  multi-disciplinary  teams.  They  also 
recognize  the  systematic  or  analytical  approach  that  systems  engineering  must  employ  by 
referring  to  the  “scientific  method.”  Lastly,  they  astutely  identify  the  need  for  systems 
thinking  in  systems  engineering,  where  one  must  take  a  holistic  approach  to  solving 
system  domain  problems  rather  than  over-emphasizing  individual  subsystems  at  the 
expense  of  the  whole. 

In  his  1967  definition,  Chestnut  went  on  to  highlight  the  difference  between 
operating  a  system  and  engineering  a  system:  “the  overall  problem  of  systems 
engineering  is  composed  of  two  parts,  one  being  the  systems  engineering  associated  with 
the  way  that  the  operating  system  itself  works  and  the  other  with  the  systematic  process 
of  performing  the  engineering  and  associated  work  in  producing  the  operating  system” 
(p.  12).  Modem  day  systems  engineering  life  cycle  models  do  not  stop  once  the 
“engineering”  part  of  the  process  is  complete.  Rather,  they  depict  the  operations, 
maintenance  and  disposal  phases  of  the  end-to-end  process  as  well.  During  the  1990s, 
Checkland  built  upon  these  concepts  by  defining  systems  engineering  as  “the  set  of 
activities  that  together  lead  to  the  creation  of  a  complex  man-made  entity  and/or  the 
procedures  and  information  flows  associated  with  its  operation”  (1993,  p.  138).  This 
particular  definition  highlights  the  interaction  between  components  in  a  system. 
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Other  modem  day  definitions  of  systems  engineering  include: 

1 .  “The  design  of  a  complex  interrelation  of  many  elements  (a  system)  to 
maximize  an  agreed-upon  measure  of  system  performance,  taking  into 
consideration  all  of  the  elements  related  in  any  way  to  the  system, 
including  utilization  of  worker  power  as  well  as  the  characteristics  of  each 
of  the  system’s  components.”  (Parker,  1994,  p.  498) 

2.  “An  interdisciplinary  collaborative  approach  to  derive,  evolve,  and  verify 
a  life-cycle  balanced  system  solution  which  satisfies  customer 
expectations  and  meets  public  acceptability.”  (Institute  of  Electrical  and 
Electronics  Engineers  [IEEE]  1220,  1998,  p.  11) 

3.  “An  interdisciplinary  approach  and  means  to  enable  the  realization  of 
successful  systems.”  (INCOSE,  2004,  p.  12) 

In  addition  to  the  core  themes  of  interdisciplinary  teams,  complexity,  human 
interactions  and  systems  thinking,  systems  engineering  is  grounded  in  its  basic  processes 
of  planning  (arrangement  of  specific  steps),  designing  (applying  scientific  and 
engineering  methods)  and  management  (skillfully  leveraging  resources).  The  last  two 
definitions  cited  above  from  the  Institute  of  Electrical  and  Electronics  Engineers  (IEEE) 
and  INCOSE  highlight  the  need  for  systems  to  meet  customers’  expectations  and  be 
“successful,”  alluding  to  the  importance  of  meeting  stakeholder  needs. 

B.  PERSPECTIVES  ON  THE  ROLE  OF  A  SYSTEMS  ENGINEER 

The  primary  functions  of  a  systems  engineer  (one  who  practices  systems 
engineering)  can  be  framed  in  various  ways.  However,  there  are  a  number  of  common 
trends  that  appear  in  the  functions  associated  with  a  systems  engineer.  The  Systems 
Engineering  Body  of  Knowledge  (SEBoK)  highlights  the  following  primary  functions  of 
a  systems  engineer:  he  or  she: 

•  Supports  an  interdisciplinary  approach 

•  Elicits  and  translates  customer  needs  into  specifications 

•  Supports  the  systems  engineering  life  cycle  processes 

•  Analyzes,  specifies,  designs  and  verifies  the  system  to  ensure  that  its 
functional,  interface,  performance,  physical,  and  other  quality 
characteristics — as  well  as  cost — are  balanced  to  meet  the  needs  of  the 
system 

•  Ensures  the  elements  of  the  system  fit  together  to  accomplish  the 
objectives  of  the  whole 
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•  Ultimately  satisfies  the  needs  of  the  customers  and  other  stakeholders  who 
will  acquire  and  use  the  system  (Pyster,  dwell,  Hutchison,  Enck, 
Anthony,  Henry,  &  Squires,  2012,  p.  5). 

The  GRCSE  states  that  the  role  of  the  systems  engineer  includes: 

•  Understanding  the  intended  purpose,  operational  context,  and  concept  of 
use  of  the  proposed  system 

•  Appreciating  the  interests,  purposes,  values  of  multiple  stakeholders  and 
combining  these  into  a  coherent  representation  of  the  system  requirements. 

•  Understanding  the  technology  that  may  be  applied  in  the  system 

•  Appreciating  the  life  cycle  implications  of  systems  and  incorporating  life 
cycle  perspectives  into  systems  design 

•  Evaluating,  selecting,  and  developing  system  solutions  to  satisfy  customer 
needs  and  project  objectives  (GRCSE,  2012,  p.  1). 

C.  DEFINING  THE  ROLE  OF  THE  SYSTEMS  ENGINEER  AT  SSC 

ATLANTIC 

Defining  the  KSAs  required  for  a  systems  engineer  in  a  complex  organization 
such  as  SSC  Atlantic  comes  with  its  challenges.  The  first  challenge  is  defining  the  role 
of  the  systems  engineer  in  a  manner  which  can  be  accepted  across  a  large,  matrix 
organization.  As  of  July  2013,  SSC  Atlantic  consists  of  just  over  4,000  U.S.  government 
employees — over  half  of  which  work  for  the  engineering  department  (actually  known  as 
the  engineering  “competency”).  For  the  purposes  of  this  paper,  the  SSC  Atlantic 
engineering  competency  will  be  referred  to  as  a  “department”  so  as  not  to  confuse  it  with 
the  classical  definition  of  “competency,”  which  will  be  addressed  later  in  the  paper.  The 
SSC  Atlantic  engineering  department  engineers,  scientists,  technicians  and  specialists  are 
all  involved  in  systems  engineering  in  various  capacities.  Over  240  integrated  product 
teams  (IPTs)  in  SSC  Atlantic  work  to  deliver  various  IT-related  end  item  products  to 
Naval,  Joint  and  Coalition  warfighting  customers.  The  range  of  engineering  processes, 
technologies,  missions  and  customers  supported  by  the  SSC  Atlantic  engineering 
department  covers  a  wide  spectrum.  Determining  the  desired  competency  areas  and 
KSAs  for  a  lead  systems  engineer  on  any  one  of  these  IPTs  may  be  a  relatively 
straightforward  task.  However,  determining  a  common  set  of  KSAs  for  a  lead  systems 
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engineer  for  all  240  IPTs  becomes  significantly  more  challenging.  This  task  requires 
observing  the  common  duties  or  responsibilities  associated  with  all  of  these  roles. 

In  February  2013,  SSC  Atlantic  engineering  department  leaders  decided  to 
establish  the  following  core  duties  for  an  IPT  technical  lead,  which  is  closely  related  to 
the  role  of  a  the  lead  systems  engineer  on  an  IPT: 

•  Identify  scope  of  engineering/technical  tasks  on  an  IPT 

•  Determine  what  technical  expertise  is  needed  to  support  the  IPT  based  on 
customer  needs 

•  Determine  the  roles/KSAs  needed  on  an  IPT  and  when  to  submit  demand 
signals  out  to  the  appropriate  competencies 

•  Support/lead  technical  reviews  for  the  IPT 

•  Responsible  for  the  review  of  engineering/technical  deliverables; 
Responsible  for  the  technical  quality  of  the  work  products  produced  by  the 
IPT 

•  Work  with  portfolio  systems  engineers  to  integrate  into  enterprise 
architecture  /  system  of  systems  /  mission 

•  Serve  as  technical  advisors  for  the  IPT  and  adhere  to  the  latest  SSC 
Atlantic  technical  initiatives 

An  individual  serving  the  role  of  an  IPT  technical  lead  may  also  serve  as  the  IPT 
lead  or  program  manager.  The  role  of  an  SSC  Atlantic  IPT  technical  lead  is  compared  to 
that  of  a  systems  engineer,  as  defined  by  the  aforementioned  sources  in  Table  1. 


Systems  Engineer  Role  Key  Concepts 

SEBoK 

GRCSE 

SSC  Atlantic 

Integrating  different  disciplines  and  technologies 

X 

X 

Addressing  operational  /  stakeholder  needs 

X 

X 

X 

Systems  Engineering  life  cycle  processes 

X 

X 

X 

Requirements  traceability  through  design, 

verification,  validation 

X 

X 

System  elements  fitting  together  to  meet  the 

objectives  of  the  whole 

X 

X 

Satisfying  customer  needs 

X 

X 

Balancing  cost,  schedule  and  performance 

X 

X 

Table  1.  SE  Role  Key  Concepts  Stressed  by  Different  Organizations  (After  GRCSE, 

2012,  p.  1;  Pyster  et  al.,  2012,  p.  9) 
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Comparing  the  SE  role  perspectives  of  SEBoK  and  GRCSE,  both  stress  the 
importance  of  addressing  operational  needs,  requirements  traceability,  balancing  the 
tradeoffs  between  cost,  schedule  and  performance,  satisfying  customer  needs  and  SE  life 
cycle  processes.  When  comparing  the  SSC  Atlantic  IPT  technical  lead  role  to  that  of  the 
systems  engineer  (as  defined  by  SEBoK  and  GRCSE),  there  appears  to  be  a  gap  in  the 
areas  of  requirements  traceability,  customer  needs  satisfaction  and  the  balancing  of  cost, 
schedule  and  performance  (GRCSE,  2012,  p.  1;  Pyster  et  al.,  2012,  p.  9).  However,  there 
are  other  defined  IPT  roles  within  SSC  Atlantic,  which  specifically  address  these  three 
functional  areas — the  requirements  engineer  (who  addresses  requirements  traceability), 
the  tester  (who  validates  user  needs  are  met)  and  the  project  manager  (who  balances  cost, 
schedule  and  performance).  This  frees  up  the  IPT  technical  lead  role  to  focus  on  areas  of 
importance  that  are  not  stressed  in  classical  systems  engineering  roles,  such  as  those 
associated  with  scoping  engineering  tasks,  managing  engineering  resources,  planning 
technical  reviews,  and  conducting  technical  deliverable  reviews. 

D.  COMPETENCY  AND  COMPETENCY  FRAMEWORKS 

Simply  understanding  the  basic  duties  that  need  to  be  performed  in  a  role  such  as 
a  systems  engineer  or  a  project  manager  is  insufficient.  One  must  also  define  the  KSAs 
needed  to  perform  those  duties  effectively  and  organize  them  in  such  a  way  for  an 
individual  to  visualize  a  developmental  roadmap  for  competency  development.  In  order 
to  understand  the  various  competency  model  frameworks  that  can  be  leveraged  to  help 
define  the  developmental  needs  of  systems  engineers,  one  must  first  examine  the  basic 
concepts  of  competency  and  competency  frameworks.  The  term  capability  refers  to  “the 
ability  to  deliver  a  product  or  service”  (Holt  &  Perry,  201 1,  p.  5).  In  the  context  of  this 
paper,  the  end  goal  is  to  improve  SSC  Atlantic’s  ability  to  provide  the  service  of 
delivering  superior  IT  solutions  through  systems  engineering.  In  other  words,  the  goal  is 
to  improve  SSC  Atlantic’s  systems  engineering  capability. 

The  term  competency  is  defined  as  “an  important  skill  that  is  needed  to  do  a  job” 
(Holt  &  Perry,  2011,  p.  2)  while  a  competency  framework  “describes  a  set  of 
competencies  (the  ‘things’  that  are  measured  to  demonstrate  competence)  that  are 
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applicable  to  a  particular  field”  (Holt  &  Perry,  201 1,  p.  6).  For  the  purposes  of  this  paper, 
competencies  are  referred  to  as  competency  areas.  These  competency  areas  are  made  up 
of  various  knowledge,  skills,  and  abilities  (KSAs).  Figure  2  illustrates  how  a  competency 
framework  can  be  subdivided  into  multiple  competency  areas,  each  of  which  contains 
any  number  of  KSAs.  KSAs  can  be  developed  via  a  number  of  workforce  development 
methods.  Professional  development,  OJT  and  other  forms  of  workforce  development 
methods  are  further  defined  and  discussed  in  Chapter  V.  Competency  models  and 
frameworks  also  come  equipped  with  “a  scale  for  assessing  the  level  of  individual 
proficiency  in  each  competency”  (Pyster  et  al.,  2012,  p.  694). 


Competency 

Framework 


Competency 
Area  #1 

Competency 
Area  #2 

Competency 
Area  #3 

KSA  #1.1 

KSA  #2.1 

KSA  #3.1 

KSA  #1.2 

KSA  #2.2 

KSA  #3.2 

* 

• 

• 

* 

* 

* 

* 

* 

* 

KSA  #1.X 

KSA  #2.X 

KSA  #3.X 

Figure  2.  Basic  Competency  Framework  with  Associated  Competency  Areas 

and  KSAs 


When  applied  to  systems  engineering,  KSAs  can  be  characterized  by  groups  of 
competency  areas  known  as  competency  vectors  or  dimensions.  Example  competency 
vectors  include  systems  engineering  life  cycle  phase,  product  type,  engineering  discipline 
or  mission  area.  The  SEBoK  asserts,  “SE  competency  must  be  viewed  through  its 

relationship  to  the  systems  life  cycle,  the  SE  discipline,  and  the  domain  in  which  the 
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engineer  practices  SE”  (Pyster  et  al.,  2012,  p.  694).  Each  of  these  perspectives  may  be  its 
own  competency  vector.  Figure  3  illustrates  how  competency  vectors  allow  for  the 
grouping  of  competency  areas. 


Competency  Framework 


Competency  Vector  A 


Competency  Vector  B 


Competency 
Area  Al 

Competency 
Area  A2 

Competency 
Area  A3 

Competency 
Area  B1 

Competency 
Area  B2 

Competency 
Area  B3 

KSA  Al.l 

KSA  A2.1 

KSA  A3.1 

KSA  Bl.l 

KSA  B2.1 

KSA  B3.1 

KSA  A1.2 

KSA  A2.2 

KSA  A3. 2 

KSA  B1.2 

KSA  B2.2 

KSA  B3.2 

KSA  Al.X 

KSA  A2.X 

KSA  A3.X 

KSA  Bl.X 

KSA  B2.X 

KSA  B3.X 

Figure  3.  Competency  Framework  Employing  Competency  Vectors 


E.  SE  COMPETENCY  MODEL  USE  CASES 

The  SEBoK  states  that,  “SE  competency  models  can  be  used  to  explicitly  state 
and  actively  manage  the  SE  competencies  within  an  organization”  (Pyster  et  al.,  2012, 
p.  694).  More  specifically,  these  competency  models  are  useful  in  a  number  of 
organizational  processes — namely  hiring,  IPT  staffing,  organizational  capability 
development,  and  individual  competency  development.  Appendix  A  depicts  the  process 
model  for  each  of  these.  These  organizational  processes,  or  use  cases  are  summarized  as 
such: 


•  Hiring — KSAs  defined  in  a  competency  model  can  be  used  throughout 

the  recruiting  and  hiring  process  in  order  to  fill  needed  positions. 
Potential  candidates  for  employment  that  are  assessed  at  higher  CDM 
stages  or  with  more  of  the  requisite  KSAs  would  be  more  likely  to  be 
selected/hired  for  systems  engineering  positions. 
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•  IPT  staffing — The  IPT  staffing  process  begins  with  an  external 
customer’s  need  for  SE  services.  The  IPT  Lead  then  works  with  other 
members  of  engineering  department  management  to  determine  what  roles, 
subroles  and  KSAs  are  needed  in  order  to  provide  those  services.  The 
appropriate  engineering  supervisors  then  use  each  employee’s  KSA  data 
to  determine  who  is  the  most  capable  of  providing  those  needed  services 
for  a  particular  IPT  assignment. 

•  Organizational  capability  development  &  training  identification — 

Engineering  department  managers  can  look  across  the  aggregate 
workforce  to  determine  where  employees  are  most  competent  (where  they 
have  the  KSAs)  and  where  they  need  further  development  (where  they 
don ’t  have  the  KSAs)  in  order  to  satisfy  present  and  future  demand  for  SE 
services.  These  KSA  gaps  in  the  workforce  become  priority  competency 
areas  where  optimal  workforce  development  methods  should  be  identified 
and  executed.  For  example,  if  a  large  portion  of  the  engineering 
department  workforce  lacks  the  requisite  KSAs  to  perform  interface 
management,  then  a  potential  solution  would  be  to  develop  or  acquire 
structured  interface  management  training  that  would  address  this 
capability  gap. 

•  Individual  competency  development — Individuals  understand  which 
competency  areas  and  KSAs  they  need  to  develop  in  order  to  advance 
through  the  entry,  intermediate,  advanced  and  expert  stages  of  their  SE 
role  competency  development  model. 

F.  EXISTING  SE  COMPETENCY  FRAMEWORKS 

Within  the  DoD  and  industry,  there  are  a  number  of  existing  SE  competency 
frameworks  that  describe  SE  competency  areas  and  associated  KSAs.  The  SEBoK 
discusses  and  summarizes  the  SE  competency  models  employed  by  INCOSE,  MITRE, 
DAU,  NASA,  the  Software  Engineering  Institute  (SEI)  and  the  capability  maturity  model 
integration  (CMMI)  as  shown  in  Table  2.  Each  of  these  five  competency  models  is 
relatively  young,  as  the  earliest  (those  of  SEI  and  MITRE)  were  authored  in  2007. 
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Competency  Model 

Individual  Level 

Date 

Author(s) 

Purpose 

Development  Method 

Competency 

Model 

INCOSE  UK  WG 

2010 

INCOSE 

Identify  the  competencies  required  to  conduct 
good  systems  engineering 

INCOSE  Working  Group 

INCOSE  (2010) 

M ITRE  ( 'om pete ncy 

Model 

2007 

MITRE 

To  define  new  curricula  systems  engineering  and 
to  assess  personnel  and  organizational 
capabilities 

Focus  groups  as  described 
in  Trudeau  (2005) 

Trudeau  (2005), 

MITRE  2007 

SPRDE-SE/PSE 

C  ompetency  Model 

2010 

DAU 

Assess  U.S.  DoD  Civilian  acquisition  workforce 
capabilities 

DoD  and  DAU  internal 

development 

DAU  (2010) 

A  PPL  1 .  Com  petency 

Model 

2009 

NASA 

To  improve  project  management  management 
and  systems  engineering  at  NASA 

NASA  internal 

development 

APPEL  (2009) 

CMM1  for  Development 

2007 

SEI 

Process  improvement  maturity  model  for  the 
development  of  products  and  services 

SEI  Internal  Development 

SEI  (2007) 

Table  2.  Summary  of  SE  Competency  Models  (From  Pyster  et  al.,  2012,  p.  696) 


Rather  than  compare  and  contrast  all  five  models,  the  three  arguably  most 
relevant  to  SSC  Atlantic  systems  engineering  will  be  discussed — DAU,  NASA  and 
INCOSE.  The  DAU  SPRDE-SE/PSE  competency  model  is  the  most  highly  correlated 
model  as  it  is  used  DoD-wide  and  SSC  Atlantic  is  a  DoD/DON  engineering  and 
acquisition  organization.  As  of  April  2013,  878  SSC  Atlantic  employees  were  designated 
as  being  in  a  DAU  SPRDE-SE/PSE  billet.  NASA — a  Federal  organization — has  been  a 
pioneer  in  the  field  of  SE  for  decades.  NASA  offers  a  mature  SE  competency  framework 
(known  as  the  Academy  of  Program/Project  Engineering  Leadership  (APPEL) 
competency  model)  centered  on  engineering  and  delivering  complex  systems.  Therefore, 
the  NASA  APPEL  model  is  largely  relevant  to  the  types  of  services  that  are  provided  at 
SSC  Atlantic.  The  INCOSE  model  is  perhaps  the  most  pervasive  competency  model  and 
is  embraced  by  many  members  of  the  international  SE  community.  INCOSE’s  SE 
competency  model  is  closely  correlated  with  those  of  DAU,  NASA  and  other 
Federal/DoD  organizations,  but  also  offers  industry’s  best-of-breed  representation  of  a 
SE  competency  framework.  INCOSE  also  administers  the  most  well-known  SE 
certification  program  in  the  world — Certified  Systems  Engineering  Professional  (CSEP). 

While  not  discussed  in  this  thesis,  it  should  be  noted  that  the  Project  Management 
Institute  (PMI)  and  skills  framework  for  the  information  age  (SFIA)  offer  competency 
models  in  the  areas  of  project/program  management  and  information  technology  which 
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are  both  closely  related  to  the  discipline  of  systems  engineering  as  well  as  highly  relevant 
to  the  types  of  services  commonly  provided  by  SSC  Atlantic. 

G.  COMPETENCY  DEVELOPMENT  MODEL  STAGES 

Competency  models  or  frameworks  typically  come  equipped  with  stages  that 
define  the  levels  of  competence  (or  levels  of  KSAs)  that  an  individual  can  develop  in  a 
given  role.  Most  competency  frameworks  employ  a  three,  four  or  five  stage  construct. 
For  example,  INCOSE  uses  the  following  four  stage  construct  to  define  an  individual’s 
level  of  expertise  at  various  competency  development  levels: 

•  Stage  1:  Awareness — understands  basic  concepts;  little  to  no  experience 

•  Stage  2:  Supervised  Practitioner — some  real  experience  of  the 
competency;  application  of  techniques  and  concepts  as  part  of  his/her 
work 

•  Stage  3:  Practitioner — provides  guidance  and  leads  activities  in  this  area; 
supervises  and/or  leads  teams  or  groups  of  people 

•  Stage  4:  Expert — leads  the  field  in  a  particular  area;  defines  best- 
practices,  policies  or  processes  within  an  organization  or  industry 
(INCOSE,  2010) 

GRCSE  uses  the  competency  development  levels  or  stages  shown  in  Table  3. 


Level  1:  Participate  (Know) 

Performs  fundamental  and  routine  SE  activities  while  supporting  a  Level  ll-IV 
systems  engineer  as  a  member  of  a  project  team. 

Level  II:  Apply  (Perform) 

Performs  SE  activities  for  a  subsystem  or  simple  project  (e.g.,  no  more  than  two 
simple  internal/external  interfaces,  simpler  contracting  processes,  smaller 
team/budget,  and  shorter  duration). 

Level  III:  Manage  (Lead) 

Performs  as  a  systems  engineer  lead  for  a  complex  project  (e.g.,  several  distinct 
subsystems  or  other  defined  services,  capabilities,  or  products  and  their 
associated  interfaces). 

Level  IV:  Guide  (Strategize) 

Oversees  SE  activities  for  a  program  with  several  systems  and/or  establishes  SE 
policies  at  the  top  organizational  level. 

Table  3.  GRCSE  Competency  Proficiency  Levels  (From  GRCSE,  2012,  p.  108) 


Other  competency  frameworks  employ  very  similar  competency  development  (or 
proficiency)  levels  where,  generally  speaking,  the  first  level  is  knowing  or  understanding; 
the  second  level  is  executing  SE;  the  third  level  involves  leading  teams  in  SE;  and  the 
fourth  level  involves  defining  best  practices,  policies  and  generally  governing  how  SE  is 
accomplished  within  an  entire  organization.  Chapter  III  examines  SSC  Atlantic’s 
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implementation  of  a  SE  competency  framework  which  utilizes  a  similar  four-stage 
development  concept. 


H.  COMPETENCY  VECTORS 

A  competency  vector  (also  known  as  a  competency  dimension),  is  a  logical 
grouping  of  competency  areas.  Major  competency  vectors  for  a  competency  model  vary 
from  one  framework  to  another.  However,  when  compared  side-by-side,  the  INCOSE, 
DAU  SPRDE-SE/PSE  and  NASA  SE  competency  frameworks  display  an  interesting 
trend.  All  three  frameworks  address  the  SE  technical  processes,  also  known  as  the 
systems  engineering  “vee.”  All  three  incorporate  the  SE  technical  management 
processes  as  well,  encompassing  such  competency  areas  as  risk  management, 
requirements  management  and  configuration  management.  All  three  incorporate  various 
supporting  techniques  that  span  competency  areas  as  system  assurance, 
reliability/availability/maintainability  (RAM),  safety,  and  software  engineering;  however, 
these  techniques  are  much  more  varied  when  compared  between  frameworks.  All  three 
frameworks  also  incorporate  some  form  of  competency  vector  associated  with  leadership 
skills  or  personal  attributes.  Two  of  the  three  (INCOSE  and  NASA)  refer  to  some  form 
of  domain  knowledge  which  provides  the  mission  or  context  for  why  there  is  an 
operational  need  for  the  systems  engineering  being  performed.  The  domain  competency 
vector  can  encompass  technology  areas  such  as  networks  and  sensors.  The  domain 
competency  vector  can  also  encompass  engineering  disciplines  such  as  mechanical, 
electrical  and  structural  engineering.  Table  4  provides  a  side-by-side  comparison  of  the 
three  aforementioned  SE  competency  frameworks  and  how  they  each  address  these  five 
primary  competency  vectors. 
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Competency  Model 

Competency  Vector 

INCOSE  (2010) 

DAU  SPRDE-SE/PSE 
(2010) 

NASA  (2009) 

Technical  Processes 

Core  Competencies 
(Sys  Thinking, 

Holistic  Lifecycle 
View) 

Analytical 

Competencies 

(Technical 

Processes) 

System  Design  & 

Product  Realization 

Technical  Mgt 

Processes 

Core  Competencies 
(SE  Mgt) 

Technical  Mgt 
Competencies 

Technical 

Management 

Supporting 

Techniques 

Supporting 

Techniques 

Analytical 
Competencies 
(System  Assurance, 
Software 

Engineering,  Safety, 
RAM) 

Security,  Safety  & 

Mission  Assurance 

Domain 

Domain  Knowledge 

N/A 

Internal  &  External 

Environments 

Leadership/Personal 

Attributes 

Basic  Skills  and 

Behaviors 

Professional 

Competencies 

Professional  & 

Leadership 

Development 

/Vote:  NASA  ajso  has  Human  Capital  Mgt  &  Knowledge  Mgt_  as  competency  areas 
Table  4.  Comparison  of  INCOSE,  DAU  and  NASA  SE  Competency  Vectors 


It  should  also  be  noted  that  the  SEBoK  states  that  there  are  typically  four  primary 
competency  vectors  (which  they  refer  to  as  dimensions )  to  a  SE  competency  model — 
disciplines,  life  cycle,  domain  and  mission  (Pyster  et  al.,  2012,  p.  709).  The  SEBoK  cites 
aerospace  and  medical  as  two  potential  domain  areas,  for  example  (Pyster  et  al.,  2012, 
p.  22).  In  the  context  of  SSC  Atlantic  KSAs,  the  terms  “domain”  and  “mission”  can  be 
used  relatively  interchangeably.  Examples  of  domain  or  mission  areas  related  to  SSC 
Atlantic  would  include  command  and  control,  information  operations  and  business 
operations.  For  the  purposes  of  this  paper,  domain  and  mission  are  considered  one  in  the 
same,  as  both  provide  context  for  the  SE  effort  to  be  accomplished. 

I.  DEPARTMENT  OF  NAVY  SYSTEMS  ENGINEERING  COMPETENCY 
DEVELOPMENT  MODEL 

As  previously  discussed,  all  three  of  the  aforementioned  SE  competency 
frameworks  provide  tremendous  value  and  are  closely  related  to  the  SE  practices 
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conducted  at  SSC  Atlantic.  So  which  framework  should  be  chosen  for  tailoring  at  SSC 
Atlantic  and  the  naval  community  at  large? 

A  Pragmatic  Guide  to  Competency  states: 

When  it  comes  to  choosing  between  frameworks,  then  the  scope  of  each 
and  their  intended  audience  becomes  very  important.  This  can  lead  to 
problems,  however,  as  it  is  very  rare  that  a  single  person  will  have  their 
entire  skillset  chosen  by  a  single  framework... One  way  to  address  this  is 
to  look  for  a  common  reference  that  can  be  used  as  a  starting  point  for 
mapping  between  the  various  competency  frameworks.  (Holt  &  Perry, 
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Tasked  by  DASN  RDT&E  with  bringing  together  and  fusing  the  competency 
areas  of  the  aforementioned  SE  competency  frameworks  in  addition  to  those  employed 
by  Boeing  and  Naval  Undersea  Warfare  Center  (NUWC),  the  Naval  Postgraduate  School 
(NPS)  has  developed  one  common  reference  that  can  truly  be  used  as  the  “north  star”  for 
Navy  and  U.S.  Marine  Corps  SE  organizations — the  naval  SE  CDM.  This  thesis 
contributed  to  the  development  of  the  Naval  SE  CDM,  which  focuses  on  the  competency 
vectors  for  SE  technical  processes,  technical  management  processes  and  supporting 
techniques.  The  naval  SE  CDM  deliberately  leaves  domain  and  leadership  skill 
competency  vectors  outside  of  its  scope  for  other,  more  appropriate  competency 
reference  models  and  frameworks  to  address  and  define.  Figure  4  illustrates  how  five 
different  competency  models  were  fused  into  the  naval  SE  CDM  developed  by  the  Naval 
Postgraduate  School. 
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Figure  4.  Evolution  of  the  Naval  SE  CDM  Developed  by  NPS  (From  Alexander, 

2013,  p.  29) 


The  result  of  the  NPS  competency  model  synthesis  was  25  different  competency 
areas  (also  known  as  competencies)  with  over  2,000  KSAs  identified  for  the  naval  SE 
CDM.  For  the  purposes  of  developing  a  SE  competency  framework  for  SSC  Atlantic,  the 
naval  SE  CDM  provides  a  wide  array  of  KSAs  from  which  to  choose,  along  with 
recommended  CDM  stages  (levels)  for  each  individual  knowledge,  skill  or  ability.  It 

should  be  noted  that  three  of  the  competency  areas  originally  identified  in  Version  3  of 

22 


the  naval  SE  CDM  were  removed  from  the  model  as  they  were  not  specific  to  systems 
engineering;  hence,  the  mention  of  28  competency  areas  (or  competencies)  in  Figure  4. 
The  resulting  25  naval  SE  CDM  competency  areas  are  as  such: 

•  Technical  basis  for  cost 

•  Modeling  &  simulation 

•  Safety  assurance 

•  Stakeholder  requirements  definition 

•  Requirements  analysis 

•  Architecture  design 

•  Implementation 

•  Integration 

•  Verification 

•  Validation 

•  Transition 

•  System  assurance 

•  Reliability,  availability  and  maintainability  (RAM) 

•  Decision  analysis 

•  Technical  planning 

•  Technical  assessment 

•  Configuration  management 

•  Requirements  management 

•  Risk  management 

•  Technical  data 

•  Interface  management 

•  Software  engineering 

•  Acquisition 

•  Systems  of  systems 

•  Systems  thinking 
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III.  APPLYING  SE  COMPETENCY  AREAS  TO  SSC  ATLANTIC 


A.  KNOWLEDGE,  SKILLS  AND  ABILITIES  FOR  DIFFERENT  USE  CASES 

Chapter  II  introduced  various  SSC  Atlantic  use  cases  that  leverage  KSA  data.  In 
order  to  determine  which  competency  vectors,  competency  areas  and  associated  KSAs 
SSC  Atlantic  should  adopt  for  its  diverse  set  of  systems  engineers,  one  must  gain  a 
deeper  appreciation  for  how  the  KSA  data  will  be  used.  Three  of  these  use  cases — 
recruiting/hiring,  individual  competency  development  and  training  identification 
highlight  the  need  for  KSA  data  at  three  completely  different  levels  of  granularity  (or 
abstraction). 

1.  KSAs  for  Recruitment  and  Hiring  of  Systems  Engineers 

In  order  to  recruit  and  hire  an  employee  at  SSC  Atlantic,  a  hiring  package  must  be 
developed  which  includes  position  description  information.  This  position  description 
includes  information  such  the  individual’s  pay  grade,  job  series  and  clearance 
requirements.  It  also  includes  information  regarding  the  individual’s  duties  and  KSAs. 
For  a  typical  hiring  package,  there  are  approximately  five  KSAs  cited  in  the  position 
description.  Therefore,  when  recruiting  and  hiring  a  new  systems  engineer  into  the  SSC 
Atlantic  organization,  only  a  limited  set  of  KSAs  will  actually  be  specified.  This  requires 
the  systems  engineering  KSAs  to  be  used  for  the  purpose  of  hiring  and  recruitment  to  be 
very  broad.  For  example,  if  there  are  five  competency  vectors  relevant  to  a  systems 
engineer’s  assigned  duties,  then  the  position  description  would  only  refer  to  about  one 
KSA  per  competency  vector.  A  shortened  KSA  for  such  a  case  might  read  something 
like,  “knowledge  of  the  systems  engineering  technical  management  processes”  or  “basic 
understanding  of  command  and  control  as  it  applies  to  IT  systems.” 

2.  KSAs  for  Individual  Competency  Development 

Since  2008,  SSC  Atlantic  competency  development  models  (CDMs)  for 
engineering  divisions  have  typically  consisted  of  approximately  10  to  15  KSAs  per 
competency  development  stage.  For  example,  a  systems  engineer  currently  certified  at 
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the  intermediate  stage  might  be  required  to  demonstrate  proficiency  in  12  different  KSAs 
in  order  to  progress  to  the  level  of  advanced.  Since  there  are  four  stages  in  an  SSC 
Atlantic  CDM,  this  equates  to  roughly  50  KSAs  per  CDM  for  any  given  role  that 
individual  might  fulfill.  In  this  case,  we  have  approximately  ten  times  as  many  KSAs 
defined  for  a  systems  engineer  than  we  do  in  the  use  case  associated  with  hiring  and 
recruitment.  For  this  level  of  detail,  it  would  be  insufficient  to  simply  state  that  a  systems 
engineer  must  have  “knowledge  of  the  systems  engineering  technical  management 
processes.”  Instead,  a  basic  KSA  for  a  systems  engineer’s  CDM  might  read  something 
like,  “ability  to  perform  requirements  management,”  where  requirements  management  is 
one  of  many  technical  management  processes. 

3.  KSAs  for  the  Identification  of  Training  Needs 

When  individuals  seek  to  develop  specific  KSAs  for  which  they  demonstrate  little 
to  no  proficiency,  they  may  seek  to  find  available  training  opportunities.  Oftentimes,  the 
level  of  KSA  granularity  described  in  an  SSC  Atlantic  CDM  of  approximately  50  KSAs 
is  insufficient.  For  example,  a  systems  engineer  may  need  to  develop  a  basic  ability  or 
skill  in  using  requirements  management  tools.  In  the  CDM  for  a  systems  engineer,  one 
might  find  the  KSA,  “ability  to  perform  Requirements  Management  for  complex  IT 
systems.”  However,  more  detailed  KSAs  might  not  be  identified  for  requirements 
management  tools.  For  this  reason,  there  is  an  additional  need  for  an  even  larger  quantity 
of  KSAs  to  be  specified  for  systems  engineers  that  may  add  up  to  the  hundreds  or  even 
thousands  of  KSAs.  This  allows  a  systems  engineer  to  search  for  KSAs  and  associated 
training  opportunities  that  can  fulfill  unique  developmental  needs.  For  SSC  Atlantic, 
Total  Workforce  Management  Services  (TWMS)  is  the  tool  used  to  search  for  KSAs,  find 
associated  training  opportunities  and  add  these  training  events  to  individual  development 
plans.  Table  5  summarizes  the  three  primary  use  cases  for  KSA  usage  and  how  they 
differ  in  terms  of  the  typical  quantity  of  KSAs  they  use.  Figure  5  illustrates  how  a  single 
KSA  used  for  recruiting  and  hiring  translates  into  usage  in  the  other  two  use  cases. 
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Use  Case 

Source 

Typical  #  of 
KSAs 

Recruiting  & 
Hiring 

Position  description  for  the 
job  of  a  systems  engineer 

5 

Individual 

Competency 

Development 

CDM  for  a  systems  engineer 

50 

Training  Needs 
Identification 

Total  Workforce 
Management  Services 
(TWMS)  KSA  &  Training 
Database 

500 

Table  5.  SSC  Atlantic  KSA  Use  Cases  and  Typical  KSA  Quantities 


How  a  single  KSA  associated  with  Recruiting  and  Hiring 
translates  to  other  use  cases 


Recruiting  &  Hiring 


Ability  to  apply 
Technical  Management 
Processes  in  the 
engineering  of  complex 
IT  systems 


=> 


Individual 

Competency 

Development 


Ability  to  perform 
Requirements 
Management  for 
complex  IT  systems 


Ability  to  perform 
Configuration 
Management  for 
complex  IT  systems 


Ability  to  perform 
Risk  Management  for 
complex  IT  systems 


+  7  more 


=> 


Training 

Identification 


Ability  to  maintain 
requirements 
traceability  by  using  a 
requirements 
traceability  matrix 

Ability  to  manipulate 
requirements 
management  tools  in 
the  execution  of 
requirements 
management 


Ability  to  develop  a 
requirements 
management  plan 

Ability  to  identify 
technical  risks 

Knowledge  of  risk 
mitigation  strategies 
+  45  more 


Figure  5.  How  a  KSA  Associated  with  One  Use  Case  Translates  to  Other  Use 

Cases 
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B.  APPLYING  BLOOM’S  TAXONOMY  TO  CLARIFY  DESIRED 
KNOWLEDGE,  SKILLS  AND  ABILITIES 

KSAs  can  be  stated  at  any  level  of  granularity  to  fit  the  need  of  their  use  and  are 
stratified  across  various  competency  development  or  proficiency  stages,  such  as  entry, 
intermediate,  advanced  and  expert.  KSAs  can  also  be  classified  by  Bloom’s  taxonomy 
into  three  different  domains  and  categories.  Dr.  Benjamin  Bloom  created  Bloom’s 
taxonomy  in  1956  in  order  to  encourage  the  developing  of  KSAs  in  ways  other  than  just 
memorization  of  facts.  This  led  to  the  definition  of  three  learning  domains — cognitive, 
affective  and  psychomotor  (Bloom,  1956).  The  cognitive  domain  involves  knowledge 
and  the  development  of  intellectual  skills  (Bloom,  1956).  GRCSE  focuses  more  heavily 
on  the  cognitive  domain  than  the  other  two  domains.  The  psychomotor  domain  is 
arguably  the  least  relevant  to  SE  KSAs,  as  it  focuses  primarily  on  physical  skills. 
However,  the  affective  domain,  which  focuses  on  dealing  with  emotions,  can  also  play  a 
key  role  in  the  development  of  systems  engineers  in  the  systems  thinking  competency 
area.  The  GRCSE  highlights  the  importance  of  systems  engineers  developing  KSAs  in 
the  affective  domain: 

A  key  role  of  the  systems  engineer  is  to  lead  the  development  of  systems. 

This  role  includes  working  with  engineered  systems,  deliberately  taking  a 
systems  perspective,  and  negotiating  solutions  with  multiple,  diverse 
stakeholders.  These  requirements  of  a  systems  engineer  make  their 
proficiency  in  the  attributes  of  the  affective  domain  critical  to  their 
success.  (GRCSE,  2012,  p.  86) 

The  cognitive  and  affective  domains  of  Bloom’s  taxonomy  are  each  subdivided 
by  categories  as  shown  in  Figure  6. 
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Figure  6.  Bloom’s  Taxonomy  in  the  Cognitive  and  Affective  Domains  and  the 
Hierarchy  of  Achievement  (From  GRCSE,  2012,  p.  86) 


A  key  feature  of  the  naval  SE  CDM  is  that  it  tags  each  of  its  KSAs  with  the 
Bloom’s  domain  and  category  levels  that  are  most  applicable.  The  GRCSE  asserts  that, 
within  Bloom’s  categories  or  levels,  as  shown  in  Figure  6: 

...progression  from  one  level  to  another  is  not  only  the  result  of  more 
study,  but  also  results  from  the  direction  of  the  study  effort  to  develop  a 
different  kind  of  capability.  For  example,  progression  from  ‘Knowledge’ 
to  ‘Comprehension’  is  not  attained  by  the  same  type  of  studying  that 
achieved  the  original  knowledge...  Similarly,  ‘Analysis’  and  ‘Synthesis’ 
are  different  kinds  of  skills  that  involve  different  approaches  to  thinking 
about  the  subject  matter...  synthesis  is  not  simply  more  analysis,  but 
rather  a  different  kind  of  activity  based  on  a  different  kind  of  learning. 
(GRCSE,  2012,  p.  87) 

Certain  key  verbs  can  help  in  classifying  a  knowledge,  skill  or  ability  into  a 
Bloom’s  domain  and  category/level.  For  example,  the  ability  to  apply  (the  “application” 
category  of  the  cognitive  domain)  might  use  verbs  such  as  demonstrate,  employ,  illustrate 
or  produce.  Tables  6  and  7  from  highlight  examples  and  the  key  verbs  that  are 
commonly  associated  with  each  of  Bloom’s  cognitive  and  affective  domain  levels. 
Categorizing  KSAs  in  this  manner  will  prove  useful  in  Chapter  V,  which  looks  at  the 
optimal  ways  of  developing  KSAs. 
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Category 

Example  and  Key  Verbs 

Remembering  (Knowledge):  Recall 
previous  learned  information. 

Examples:  Recite  a  policy.  Quote  prices  from  memory  to  a 
customer.  Knows  the  safety  rules. 

Key  Words:  defines,  describes,  identifies,  knows,  labels,  lists, 
matches,  names,  outlines,  recalls,  recognizes,  reproduces, 
selects,  states. 

Understanding  (Comprehension): 

Comprehending  the  meaning, 
translation,  interpolation,  and 
interpretation  of  instructions  and 
problems.  State  a  problem  in  one's 
own  words. 

Examples:  Rewrites  the  principles  of  test  writing.  Explain  in 
one's  own  words  the  steps  for  performing  a  complex  task. 
Translates  an  equation  into  a  computer  spreadsheet. 

Key  Words:  comprehends,  converts,  defends,  distinguishes, 
estimates,  explains,  extends,  generalizes,  gives  an  example, 
infers,  interprets,  paraphrases,  predicts,  rewrites,  summarizes, 
translates. 

Applying  (Application):  Use  a 

concept  in  a  new  situation  or 
unprompted  use  of  an  abstraction. 
Applies  what  was  learned  in  the 
classroom  into  novel  situations  in  the 
work  place. 

Examples:  Use  a  manual  to  calculate  an  employee's  vacation 
time.  Apply  laws  of  statistics  to  evaluate  the  reliability  of  a 
written  test. 

Key  Words:  applies,  changes,  computes,  constructs, 
demonstrates,  discovers,  manipulates,  modifies,  operates, 
predicts,  prepares,  produces,  relates,  shows,  solves,  uses. 

Analyzing  (Analysis):  Separates 
material  or  concepts  into  component 
parts  so  that  its  organizational 
structure  may  be  understood. 
Distinguishes  between  facts  and 
inferences. 

Examples:  Troubleshoot  a  piece  of  equipment  by  using  logical 
deduction.  Recognize  logical  fallacies  in  reasoning.  Gathers 
information  from  a  department  and  selects  the  required  tasks  for 
training. 

Key  Words:  analyzes,  breaks  down,  compares, 
contrasts,  diagrams,  deconstructs,  differentiates,  discriminates, 
distinguishes,  identifies,  illustrates,  infers,  outlines,  relates, 
selects,  separates. 

Evaluating  (Evaluation):  Make 
judgments  about  the  value  of  ideas  or 
materials. 

Examples:  Select  the  most  effective  solution.  Hire  the  most 
qualified  candidate.  Explain  and  justify  a  new  budget. 

Key  Words:  appraises,  compares,  concludes,  contrasts, 
criticizes,  critiques,  defends,  describes,  discriminates,  evaluates, 
explains,  interprets,  justifies,  relates,  summarizes,  supports. 

Creating  (Synthesis):  Builds  a 
structure  or  pattern  from  diverse 
elements.  Put  parts  together  to  form 
a  whole,  with  emphasis  on  creating  a 
new  meaning  or  structure. 

Examples:  Write  a  company  operations  or  process  manual. 

Design  a  machine  to  perform  a  specific  task.  Integrates  training 
from  several  sources  to  solve  a  problem.  Revises  and  process  to 
improve  the  outcome. 

Key  Words:  categorizes,  combines,  compiles,  composes, 
creates,  devises,  designs,  explains,  generates,  modifies, 
organizes,  plans,  rearranges,  reconstructs,  relates,  reorganizes, 
revises,  rewrites,  summarizes,  tells,  writes. 

Table  6.  Categories  of  Bloom’s  Cognitive  Domain  (After  Bloom’s  Taxonomy  of 

Learning  Domains,  2013) 
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Category 

Example  and  Key  Verbs 

Examples:  Listen  to  others  with  respect.  Listen  for 
and  remember  the  name  of  newly  introduced 

Receiving  Phenomena:  Awareness,  willingness 
to  hear,  selected  attention. 

people. 

Key  Words:  asks,  chooses,  describes,  follows, 
gives,  holds,  identifies,  locates,  names,  points  to, 
selects,  sits,  erects,  replies,  uses. 

Responding  to  Phenomena:  Active  participation 
on  the  part  of  the  learners.  Attends  and  reacts  to  a 
particular  phenomenon.  Learning  outcomes  may 
emphasize  compliance  in  responding,  willingness 
to  respond,  or  satisfaction  in  responding 
(motivation). 

Examples:  Participates  in  class  discussions.  Gives 
a  presentation.  Questions  new  ideals,  concepts, 
models,  etc.  in  order  to  fully  understand  them. 

Know  the  safety  rules  and  practices  them. 

Key  Words:  answers,  assists,  aids,  complies, 
conforms,  discusses,  greets,  helps,  labels,  performs, 
practices,  presents,  reads,  recites,  reports,  selects, 
tells,  writes. 

Valuing:  The  worth  or  value  a  person  attaches  to 
a  particular  object,  phenomenon,  or 
behavior.  This  ranges  from  simple  acceptance  to 
the  more  complex  state  of  commitment.  Valuing 
is  based  on  the  internalization  of  a  set  of  specified 
values,  while  clues  to  these  values  are  expressed 
in  the  learner’s  overt  behavior  and  are  often 
identifiable. 

Examples:  Demonstrates  belief  in  the  democratic 
process.  Is  sensitive  towards  individual  and  cultural 
differences  (value  diversity).  Shows  the  ability  to 
solve  problems.  Proposes  a  plan  to  social 
improvement  and  follows  through  with 
commitment.  Informs  management  on  matters  that 
one  feels  strongly  about. 

Key  Words:  completes,  demonstrates, 
differentiates,  explains,  follows,  forms,  initiates, 
invites,  joins,  justifies,  proposes,  reads,  reports, 
selects,  shares,  studies,  works. 

Organization:  Organizes  values  into  priorities  by 
contrasting  different  values,  resolving  conflicts 
between  them,  and  creating  an  unique  value 
system.  The  emphasis  is  on  comparing,  relating, 
and  synthesizing  values. 

Examples:  Recognizes  the  need  for  balance 
between  freedom  and  responsible  behavior.  Accepts 
responsibility  for  one's  behavior.  Explains  the  role 
of  systematic  planning  in  solving  problems.  Accepts 
professional  ethical  standards.  Creates  a  life  plan  in 
harmony  with  abilities,  interests,  and  beliefs. 
Prioritizes  time  effectively  to  meet  the  needs  of  the 
organization,  family,  and  self. 

Key  Words:  adheres,  alters,  arranges,  combines, 
compares,  completes,  defends,  explains,  formulates, 
generalizes,  identifies,  integrates,  modifies,  orders, 
organizes,  prepares,  relates,  synthesizes. 

Internalizing  values  (Characterization):  Has  a 

value  system  that  controls  their  behavior.  The 
behavior  is  pervasive,  consistent,  predictable,  and 
most  importantly,  characteristic  of  the 
learner.  Instructional  objectives  are  concerned 
with  the  student's  general  patterns  of  adjustment 
(personal,  social,  emotional). 

Examples:  Shows  self-reliance  when  working 
independently.  Cooperates  in  group 
activities  (displays  teamwork).  Uses  an  objective 
approach  in  problem  solving.  Displays  a 
professional  commitment  to  ethical  practice  on  a 
daily  basis.  Revises  judgments  and  changes 
behavior  in  light  of  new  evidence.  Values  people 
for  what  they  are,  not  how  they  look. 

Key  Words:  acts,  discriminates,  displays, 
influences,  listens,  modifies,  performs,  practices, 
proposes,  qualifies,  questions,  revises,  serves, 
solves,  verifies. 

Table  7.  Categories  of  Bloom’s  Affective  Domain  (After  Bloom’s  Taxonomy  of 

Learning  Domains,  2013) 
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C.  SSC  ATLANTIC  ENGINEERING  PROCESS  FRAMEWORK 

There  are  a  number  of  different  life  cycle  models  that  serve  as  a  guide  for 
conducting  engineering  and  acquisition  processes.  The  Project  Management  Body  of 
Knowledge  (PMBoK)  provides  a  framework  for  projects  of  varying  sizes  and  degrees, 
spanning  project  initiation,  planning,  execution,  monitoring/control  and  closeout.  For  the 
Department  of  Defense,  the  defense  acquisition  management  framework  provides  an 
event-based  process  in  which  “acquisition  programs  proceed  through  a  series  of 
milestone  reviews  and  other  decision  points  that  may  authorize  entry  into  a  significant 
new  program  phase”  (Defense  Acquisition  University,  2011). 

The  systems  engineering  “Vee”  is  commonly  used  to  describe  the  systems 
engineering  processes  associated  with  requirements  development,  design, 
implementation,  integration,  verification,  validation  operations  and  sustainment.  The 
SPAWAR  Systems  Engineering  Guidebook  (SSEG),  which  is  used  by  SPAWAR 
Headquarters,  SSC  Atlantic  and  SSC  Pacific,  adopts  a  similar  model  as  shown  in  Figure 
7,  which  depicts  the  original  SSEG  process  framework.  Here  the  technical  management 
processes  are  shown  across  the  top  to  represent  that  they  are  conducted  throughout  the 
project  and  systems  engineering  life  cycle.  The  classical  SE  “Vee”  is  shown  in  the  center 
of  the  diagram  through  the  solution  design  and  production  realization  processes.  As  of 
July  2013,  the  SSEG  remains  in  beta  form  and  continues  to  be  revised  by  the  SPAWAR 
engineering  department.  Figure  8  depicts  the  updated  SSEG  process  framework,  which 
has  abandoned  the  SE  “Vee”  visual. 
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Figure  7.  Original  SSEG  Process  Framework 
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Figure  8.  SSEG  Process  Framework  as  of  July  2013 

In  May  2013,  SSC  Atlantic  established  Version  1.0  of  the  SSC  Atlantic  Systems 
Engineering  Framework  that  organizes  its  SE  process  areas  at  the  highest  level  by  the 
SSC  Project  Lifecycle,  also  known  as  the  PLC.  Figure  9  shows  how  the  PLC  combines 


33 


basic  elements  of  the  PMBoK  project  management  life  cycle  such  as  project  initiation, 
planning  and  closeout  with  systems  engineering  process  areas  such  as  requirements 
development,  design,  integration,  testing,  operations  and  sustainment.  Hence,  the  PLC 
represents  the  complementary  nature  within  SPAWAR  of  the  role  of  the  program  or 
project  manager  with  that  of  the  systems  engineer.  The  SSC  Atlantic  Systems 
Engineering  Framework  Version  1.0,  depicted  in  Figure  10,  shows  how  the  PLC  is 
supported  by  engineering  guidance  set  forth  in  the  Naval  Systems  Engineering  Guide, 
SSEG,  Defense  Acquisition  Guidebook  and  other  organizational  standard  processes  as 
well  as  by  the  technical  management  and  technical/engineering  processes  commonly 
found  in  SE  life  cycle  models. 


Figure  9.  Project  Life  Cycle 
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Figure  10.  SSC  Atlantic  SE  Process  Framework  vl.O 


While  at  the  first  level,  the  SSC  Atlantic  SE  Framework  leverages  the  PLC  as  a 
general  lifecycle  guide,  at  the  second  level,  the  Engineering  Processes  align  with  the 
competency  areas  as  defined  in  the  Naval  SE  CDM.  For  example,  requirements 
management,  interface  management  and  risk  management  are  depicted  as  technical 
management  processes,  while  stakeholder  requirements  definition  and  requirements 
analysis  show  up  as  engineering  processes,  which  are  very  closely  aligned  to  DAU 
technical  processes.  The  SSC  Atlantic  SE  Framework  serves  as  a  guide  for  systems 
engineers  to  discover  related  standard  operating  procedures,  tools,  templates,  checklists 
and  other  aids  that  can  assist  them  with  executing  SE  processes  and  developing  related 
KSAs.  The  latest  version  of  the  SSC  Atlantic  SE  Process  Framework  is  scheduled  to  be 
published  to  the  SSC  Atlantic  Command  Operating  Guide  by  the  end  of  calendar  year 
2013. 

D.  COMPETENCY  VECTORS  RELEVANT  TO  SE  AT  SSC  ATLANTIC 

While  the  systems  engineering  life  cycle  process  framework  plays  a  major  role  in 

framing  and  defining  the  KSAs  of  systems  engineers  at  SSC  Atlantic,  it  is  not  the  only 

dimension  or  competency  vector.  It  is  also  important  for  systems  engineers  to  understand 

why  they  are  engineering  and  supporting  the  solutions  they  are  delivering.  For  that 

reason,  a  critical  competency  vector  for  SSC  Atlantic  systems  engineers  must  be 

associated  with  the  domain  or  mission  that  the  engineered  solutions  ultimately  support. 

For  example,  a  naval  command  and  control  (C2)  or  information  operations  (10)  mission 
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may  require  IT  systems  that  transmit  certain  types  of  information,  improve  critical 
mission  times  or  provide  more  robust  warfighting  capabilities.  Such  mission  or 
capability  areas  can  be  framed  in  a  variety  of  different  ways.  For  example,  the  Joint 
Capability  Areas  (JCAs)  can  be  used  to  provide  a  high  level  framework  for  the  capability 
areas  associated  with  Joint  services.  In  order  for  a  systems  engineer  to  effectively  fulfill 
any  such  capability  gaps,  he  or  she  must  truly  understand  the  real  problem  at  hand  in  a 
holistic  manner. 

SSC  Atlantic’s  vision  statement  is  to  “Make  IT  Count  for  the  Warfighter  and  the 
Nation.”  IT  is  defined  as  “the  application  of  computers  and  telecommunications 
equipment  to  store,  retrieve,  transmit  and  manipulate  data”  (Daintith,  2009).  By  taking  a 
closer  look  at  the  definition  of  IT,  a  major  competency  vector  can  be  established  for  the 
development  of  IT-savvy  systems  engineers.  The  application  portion  of  this  definition 
refers  to  the  SE  process  areas  as  the  root  term  “apply”  means  “to  put  to  use,”  which 
makes  sense  as  SE  is  a  “means  to  enable  the  realization  of  successful  systems”  (INCOSE, 
2004,  p.  12).  The  other  major  component  of  IT  is  the  technology  itself — computers  and 
telecommunications  equipment.  Within  SSC  Atlantic,  the  major  technology  areas  most 
commonly  associated  with  IT  are  networks,  radio  frequency  (RF)  communications, 
computer  applications  and  sensors.  In  fact,  several  hundred  systems  engineers  at  SSC 
Atlantic  are  aligned  to  networks,  communications  or  computer  applications  as  their 
primary  competency  area.  This  naturally  leads  to  a  third  competency  vector,  which  will 
be  referred  to  as  “technology.”  Figure  1 1  depicts  the  three  primary  competency  vectors 
for  SSC  Atlantic  systems  engineers — mission,  technology  and  activities  (SE  life  cycle 
processes). 
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The  fourth  and  final  competency  vector  critical  to  the  development  of  systems 
engineers  at  SSC  Atlantic  is  one  that  is  core  to  practically  any  employee  in  any 
workplace  environment — leadership  skills.  Figure  12  depicts  the  four- vector  competency 
framework  of  mission,  technology,  activities  and  leadership  skills.  Leadership  skills 
typically  encompass  skills  or  attributes  such  as  those  related  to  oral  and  written 
communications,  conflict  management,  team  building,  strategic  thinking,  customer 
service  and  integrity.  Appendix  B  provides  a  complete  breakdown  of  the  leadership 
skills  (otherwise  known  as  personal  attributes),  definitions/indicators  and  recommended 
competency  development  stage/level.  These  leadership  skills  are  summarized  below: 

•  Accountability 

•  Communication  (oral  and  written) 

•  Conflict  management 

•  Continual  learning 

•  Creativity  /  innovation 

•  Customer  service 

•  Decisiveness  /  problem  solving 
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•  Entrepreneurship 

•  External  awareness  /  political  savvy 

•  Financial  management 

•  Flexibility  /  resilience 

•  Human  capital  management 

•  Information  management 

•  Integrity  /  honesty 

•  Interpersonal  skills 

•  Leadership  /  influence  /  negotiation 

•  Partnering  /  collaborative  performance 

•  Self-management 

•  Service  motivation 

•  Strategic  thinking  /  vision 

•  Team  building 

•  Technical  expertise 

•  Technology  credibility 

•  Technology  management 
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Figure  12.  SSC  Atlantic  Four-vector  SE  Competency  Framework 


E.  PRIORITIZATION  OF  SE  COMPETENCY  AREAS 

In  his  brief  entitled,  “A  Framework  to  Institutionalize  Systems  Engineering  Skill- 
Set”  Ebad  Jahangir  examines  the  SE  competency  frameworks  from  NASA  and  INCOSE 
and  makes  the  recommendation  that  there  are  five  primary  “critical  skills”  (most  closely 
related  to  competency  vectors) — systems  thinking,  systems  architecture,  technical 
management,  product  realization  and  leadership  skills  (2012).  Table  8  depicts  Jahangir’s 
five  critical  skills  and  associated  enabling  skills  (much  like  competency  areas).  Systems 
thinking,  as  defined  by  INCOSE,  maps  effectively  to  the  systems  thinking  competency 
area  defined  by  the  naval  SE  CDM,  as  well  as  the  mission/capability  focus  as  addressed 
by  the  mission  competency  vector.  INCOSE’s  system  architecture,  technical 
management  and  product  realization  are  directly  traceable  to  the  SE  lifecycle  (activity) 
competency  areas.  The  leadership  skills  map  directly  to  the  leadership  skills  or  personal 
attributes  competency  vector. 
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Critical  Skill 

Enabling  Skills 

Systems  Thinking 

Business  and  technology  environment 

Super-system  capability  issues 

Systems  concepts 

Stakeholder  Expectation  Definition 

System  Architecture 

Technical  Requirements  Definition 

Logical  Decomposition 

Design  Solution  Definition 

Technical  Planning 

Requirements  Management 

Interface  Management 

Technical  Management 

Technical  Risk  Management 

Configuration  Management 

Technical  Data  Management 

Technical  Assessment 

Technical  Decision  Analysis 

Product  Implementation 

Product  Realization 

Product  Integration 

Product  Verification 

Product  Validation 

Product  Transition 

Coaching 

Communication:  Verbal,  non-verbal  and  listening 

Leadership  Skills 

Communication:  Technical  report  writing 

Knowing  when  to  ask 

Lateral  thinking 

Negotiation  and  influencing 

Team  working 

Table  8.  Jahangir’s  Five  Critical  Skills  (Competency  Vectors)  for  Systems  Engineers 

(From  Jahangir,  2012) 


While  Jahangir’s  model  (as  well  as  those  of  fNCOSE,  DAU  and  NASA)  may  not 
reflect  the  IT  focus  of  SSC  Atlantic,  the  national  cybersecurity  workforce  framework 
(NCWF)  developed  by  NIST  does.  According  to  NIST,  “The  National  Cybersecurity 
Workforce  Framework  establishes  the  common  taxonomy  and  lexicon  that  is  to  be  used 
to  describe  all  cybersecurity  work  and  workers  irrespective  of  where  or  for  whom  the 
work  is  performed”  (NIST,  2011,  p.  7).  The  NCWF  defines  typical  cybersecurity 
workforce  tasks  and  KSAs  needed  in  the  areas  of  network  services,  telecommunications, 
and  computer  applications  in  sufficient  detail  to  support  the  hiring/recruiting  and 
individual  competency  development  SSC  Atlantic  use  cases. 
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Chapter  V,  Section  E  discusses  five  common  SE  use  cases  that  may  be 
encountered  by  an  SSC  Atlantic  IPT.  Each  of  these  SE  use  cases  emphasizes  the 
importance  of  different  competency  areas  and  competency  vectors.  Table  9  depicts 
which  competency  areas  and  vectors  are  emphasized  in  each  use  case  by  placing  an  “X” 
in  the  appropriate  cell.  The  Total  SE  Use  Case  Score  is  determined  by  adding  up  the 
number  of  use  cases  which  stress  the  respective  competency  area  or  vector.  Table  9  also 
depicts  the  result  of  an  analysis  conducted  by  Gelosh  in  What  Defines  a  Systems 
Engineer?  Comparing  and  Contrasting  Global  Perspectives  on  Systems-Engineering 
Competency.  Gelosh’s  analysis  compared  the  relative  importance  or  emphasis  of  a 
particular  SE  competency  area  to  the  DoD  versus  industry  (understood  as  settings  outside 
of  the  DoD).  The  far  right  column  of  Table  9  takes  the  average  score  of  the  Total  SE  Use 
Case  Score,  Gelosh’s  DoD  Score  and  Gelosh’s  Industry  Score  to  provide  a  final  score  for 
each  competency  area  and  vector.  In  summary,  this  average  or  final  score  shown  on  the 
far  right  of  Table  9  considers  various  SSC  Atlantic  SE  use  cases,  the  DoD’s  emphasis  and 
the  emphasis  of  Industry  at  large  to  prioritize  the  relative  importance  for  each  of  the 
competency  areas  and  vectors  to  be  used  by  SSC  Atlantic.  Competency  areas  and  vectors 
with  final  scores  above  3.5  are  considered  to  be  most  important.  Competency  areas  and 
vectors  with  final  scores  of  3.0  to  3.5  are  considered  moderately  important,  while  those 
with  scores  under  3.0  are  considered  mildly  important.  It  should  be  noted  that  sensitivity 
analysis  with  weighting  of  the  SSC  Atlantic  use  cases  and  Gelosh’s  scores  with  respect  to 
each  other  shift  the  rankings  to  a  certain  degree,  but  not  significantly. 
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SE  Use  Cases  (X  =  competency  area  or  yector  em 

phasized) 

G( 

Com 

ilosh 

parison 

Avg  of  SE  Use 
Case,  DoD  & 
Industry 
Scores 

Competency  Area  (or  Vector) 

Component 

Engineering 

Simple 

SE 

Complex 

SE 

Platform 

SE 

SoSE 

Total  SE  Use 
Case  Score 

DoD 

Score 

Industry 

Score 

Stakeholder  Requirements 
Definition 

X 

X 

X 

X 

X 

5 

4 

4 

4.33 

Requirements  Analysis 

X 

X 

X 

X 

X 

5 

3 

4 

4.00 

Architecture  Design 

X 

X 

X 

X 

X 

5 

3 

4 

4.00 

Software  Engineering 

X 

X 

X 

X 

4 

4 

4 

4.00 

Acquisition 

X 

X 

X 

X 

X 

5 

3 

4 

4.00 

Technology  Competency  Vector 

X 

X 

X 

X 

4 

N/A 

N/A 

4.00 

Technical  Basis  for  Cost 

X 

X 

X 

X 

X 

5 

3 

3 

3.67 

Verification 

X 

X 

X 

3 

4 

4 

3.67 

System  Assurance 

X 

X 

X 

X 

4 

4 

3 

3.67 

Decision  Analysis 

X 

X 

X 

3 

4 

3 

3.33 

Technical  Planning 

X 

X 

X 

X 

4 

4 

2 

3.33 

Configuration  Management 

X 

X 

X 

X 

4 

3 

3 

3.33 

Requirements  Management 

X 

X 

X 

3 

4 

3 

3.33 

Risk  Management 

X 

X 

X 

3 

4 

3 

3.33 

Technical  Data  Management 

X 

X 

X 

X 

4 

3 

3 

3.33 

Interface  Management 

X 

X 

X 

3 

4 

3 

3.33 

Implementation 

X 

X 

X 

X 

4 

2 

3 

3.00 

Integration 

X 

X 

X 

3 

3 

3 

3.00 

Validation 

X 

X 

X 

3 

4 

2 

3.00  ! 

Transition 

X 

X 

X 

3 

2 

4 

3.00 

Systems  Thinking 

X 

X 

X 

3 

N/A 

N/A 

3.00 

Mission  Competency  Vector 

X 

X 

X 

3 

N/A 

N/A 

3.00 

Modeling  &  Simulation 

X 

X 

X 

3 

2 

3 

2.67 

Reliability,  Availability  & 
Maintainability 

X 

X 

2 

2 

4 

2.67 

Technical  Assessment 

X 

X 

X 

3 

4 

1 

2.67 

Safety  Assurance 

X 

1 

4 

2 

2.33 

Systems  of  Systems 

X 

X 

X 

3 

1 

1 

1.67 

Table  9.  Ranking  the  Emphasis  of  Competency  Areas  and  Vectors  against  Various  SE  Use  Cases.  Gelosh  Comparison  Addresses 

DoD  versus  Industry  Perspective  (After  Gelosh,  2009) 
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Of  the  most  important  competency  areas  and  vectors,  the  stakeholder 
requirements  definition,  requirements  analysis  and  architecture  design  competency  areas 
all  represent  processes  near  the  beginning  of  the  SE  life  cycle.  The  importance  of  these 
process  areas  underscores  the  need  to  get  the  requirements  and  architecture  “right,”  lest 
the  total  cost  of  ownership  for  the  system  increase  significantly  over  the  course  of  the  life 
of  the  system.  Other  noteworthy  process  areas  that  scored  high  include  software 
engineering  and  system  assurance — two  competency  areas  that  have  continued  to 
increase  in  importance  over  the  last  several  years  due  to  systems’  reliance  on  software 
and  the  need  for  cybersecurity. 

Even  though  some  processes  were  rated  as  mildly  important,  that  is  not  to  say  that 
they  are  not  critical.  One  challenge  with  the  systems  of  systems  competency  area  is  that 
this  use  case  only  represents  a  small  percentage  of  total  projects;  therefore,  it  is  not 
currently  emphasized  a  great  deal.  It  is  also  difficult  to  train  systems  engineers  in 
systems  of  systems  engineering  (SoSE)  as  the  methodologies  associated  with  SoSE  are 
still  relatively  immature.  Systems  thinking  is  another  competency  area  that  is  arguably 
very  critical  to  SE,  yet  it  is  not  very  prescriptive,  and  thus  does  not  translate  effectively  to 
a  well-defined  process  that  can  be  monitored  and  controlled.  Safety  assurance  also  fell 
into  the  lower-scoring  category  primarily  due  to  the  fact  that  it  is  simply  a  discipline  that 
is  not  as  critical  in  the  IT  domain  as  in  those  of  a  more  physical  realm. 
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IV.  DESIGNING  A  NEW  COMPETENCY  FRAMEWORK  FOR 
SSC  ATLANTIC  SE  ROLES  AND  SUBROLES 

A.  SSC  ATLANTIC  SE  COMPETENCY  FRAMEWORK 

Chapter  II  provided  an  analysis  of  the  anatomy  of  a  competency  framework  in 
terms  of  competency  vectors,  competency  areas  and  associated  KSAs.  Chapter  II  also 
highlighted  the  critical  competency  vectors  and  competency  areas  associated  with 
performing  systems  engineering  at  SSC  Atlantic.  By  defining  the  critical  competency 
vectors  of  SSC  Atlantic  systems  engineering  to  be  missions,  activities  and  technologies , 
the  SSC  Atlantic  systems  engineering  competency  framework  depicted  in  Figure  13  is 
established.  The  competency  vector  associated  with  leadership  skills  is  not  explicitly 
depicted  in  the  framework  since  it  applies  more  broadly  to  the  entire  SSC  Atlantic  (or 
practically  any)  workforce — not  just  to  systems  engineers.  Within  each  of  the 
competency  vectors,  there  are  several  competency  areas  under  which  KSAs  are  defined. 
These  KSAs  originate  from  each  of  the  sources  defined  in  the  previous  chapters  (namely 
the  naval  SE  CDM,  INCOSE,  DAU,  NASA  and  NIST)  as  well  as  from  existing  SSC 
Atlantic  engineering  CDMs.  Each  individual  KSA  is  assigned  an  associated  competency 
development  stage — entry,  intermediate,  advanced  or  expert. 
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Figure  13.  SSC  Atlantic  Systems  Engineering  Competency  Framework 


In  order  to  define  the  associated  competency  development  model  (CDM)  for  any 
variant  (or  specialty,  subrole)  of  a  systems  engineer  role,  one  can  simply  choose  which 
sets  of  KSAs  most  apply.  In  doing  so,  care  must  be  taken  not  to  choose  too  many  KSAs 
so  as  not  to  make  the  process  of  assessing  an  individual  against  a  CDM  too  time- 
consuming.  The  need  to  control  the  number  of  total  KSAs  for  a  given  role’s  CDM  was 
discussed  in  earlier  in  Chapter  III — KSA  Use  Case  2.  Figure  14  depicts  a  high  level  view 
of  how  KSAs  in  different  competency  areas  may  be  mapped  or  assigned  to  a  systems 
engineer’s  CDM. 
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Systems  Engineer 


Figure  14.  KSAs  from  Different  Competency  Areas  Assigned  to  Systems  Engineer 

CDM 


B.  SSC  ATLANTIC  ENGINEERING  DEPARTMENT  CORE  KSAS 


Before  a  determination  can  be  made  as  to  which  KSAs  should  be  common  to  all 


systems  engineers,  one  must  first  determine  which  KSAs  are  common  (or  core)  to  all  of 
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the  SSC  Atlantic  Engineering  Department.  KSAs  chosen  as  part  of  the  “core” 
Engineering  CDM  would  be  included  in  every  engineering  department  employee’s  CDM. 
In  April  2013,  key  members  of  the  SSC  Atlantic  Engineering  Department  leadership 
reviewed  over  4,000  KSAs  to  determine  those  that  were  core  to  all  2,000+  members  of 
the  engineering  department  at  the  entry  and  intermediate  CDM  stages.  KSAs  at  the 
advanced  and  expert  stages  would  be  assumed  to  be  only  role-specific,  where  the  role  of 
a  systems  engineer  is  just  one  of  many  engineering  department  roles.  A  total  of  11 
representatives  participated  in  the  identification  of  these  core  KSAs  across  the  following 
engineering  divisions  and  departments:  Net-centric  Engineering  and  Integration; 
Computer  Applications;  Network  and  Communications;  Intelligence,  Surveillance, 
Reconnaissance  (ISR)  /  Information  Operations  (IO);  Space;  Information  Assurance;  and 
Test,  Evaluation  &  Certification.  For  each  of  the  KSAs  that  could  potentially  be 
considered  core  to  all  of  the  SSC  Atlantic  Engineering  Department’s  overarching  CDM, 
10  of  the  11  possible  votes  had  to  be  affirmative.  Of  the  4,000+  KSAs  identified  as 
potential  candidates,  62  were  ultimately  selected  as  common  to  all  of  the  SSC  Atlantic 
Engineering  Department.  Table  10  identifies  these  core  engineering  KSAs,  their 
respective  competency  area  and  associated  competency  development  stage. 
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Competency 

Vector 

Competency  Area 

KSA 

Stage 

Activity 

GENERAL 

Basic  knowledge  of  technical  and 
technical  mgt  processes 

Entry 

Activity 

GENERAL 

Knowledge  of  engineering/technical 
artifacts  required  by  SSC  Atlantic 

Entry 

Activity 

GENERAL 

Ability  to  review  engineering/technical 
artifacts  for  completeness  and  quality 

Intermediate 

Activity 

1.0  TECHNICAL  BA 

SIS  FOR  COST 

Knowledge  of  SPAWAR  accounting  and 
financial  systems 

Entry 

Activity 

1.0  TECHNICAL  BA 

SIS  FOR  COST 

Ability  to  contribute  to  timely  and 
accurate  full  cost  budget  information 
(such  as  labor,  procurement,  travel 
estimates)  to  project  managers  when 
requested 

Entry 

Activity 

1.0  TECHNICAL  BA 

SIS  FOR  COST 

Ability  to  perform  cost  estimating  on 
technical  work  products 

Entry 

Activity 

1.0  TECHNICAL  BA 

SIS  FOR  COST 

Ability  to  use  Work  Breakdown 

Structure  (WBS)  as  a  tool  for  tracking 
actual  vs.  estimated  costs  and  use  this 

information  to  revise  cost  models 
appropriately 

Entry 

Activity 

2.0  MODELING  & 

SIMULATION 

Knowledge  of  decision  support  tools, 
models,  or  simulations  that  are 
applicable  to  your  job. 

Entry 

Activity 

3.0  SAFETY 

ASSURANCE 

Understand  and  comply  with  safety 
strategies,  policies,  and  standards 

Entry 

Activity 

3.0  SAFETY 

ASSURANCE 

Understands  the  relationship  between 
reliability,  availability,  maintainability 
and  safety 

Intermediate 

Activity 

4.0  STAKEHOLDER 

REQUIREMENTS 

DEFINITION 

Able  to  identify  major  stakeholders 

Entry 

Activity 

4.0  STAKEHOLDER 

REQUIREMENTS 

DEFINITION 

Understand  the  importance  of 
requirements  traceability 

Entry 

Activity 

4.0  STAKEHOLDER 

REQUIREMENTS 

DEFINITION 

Can  support  the  elicitation  of 
requirements  from  stakeholders 

Intermediate 

Activity 

5.0 

REQUIREMENTS 

ANALYSIS 

Understands  that  there  are  different 
types  of  requirements  e.g.  functional, 
non-functional,  business  etc. 

Entry 
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Competency 

Vector 

Competency  Area 

KSA 

Stage 

Activity 

5.0 

REQUIREMENTS 

ANALYSIS 

Understands  the  importance  of 
managing  requirements  throughout  the 
lifecycle 

Entry 

Activity 

5.0 

REQUIREMENTS 

ANALYSIS 

Understands  the  need  for  good  quality 
requirements  (achievable,  verifiable, 
unambiguous,  necessary  and  sufficient, 
complete,  expressed  as  a  need, 
consistent,  and  appropriate) 

Entry 

Activity 

5.0 

REQUIREMENTS 

ANALYSIS 

Contribute  to  decomposition  of 
requirements 

Entry 

Activity 

5.0 

REQUIREMENTS 

ANALYSIS 

Contribute  to  development  of 
specification  documents 

Entry 

Activity 

5.0 

REQUIREMENTS 

ANALYSIS 

Understands  the  relationship  between 
design  and  requirements 

Intermediate 

Activity 

5.0 

REQUIREMENTS 

ANALYSIS 

Ability  to  identify  and  analyze 
requirements 

Intermediate 

Activity 

6.0  ARCHITECTUR 

E  DESIGN 

Basic  knowledge  of  the  different  types 
of  architecture 

Entry 

Activity 

6.0  ARCHITECTUR 

E  DESIGN 

Identifies  systems  interfaces  and 
interoperability  concerns. 

Entry 

Activity 

6.0  ARCHITECTUR 

E  DESIGN 

Understands  the  need  to  explore 
alternative  and  innovative  ways  of 
satisfying  the  system  need 

Entry 

Activity 

6.0  ARCHITECTUR 

E  DESIGN 

Knowledge  of  the  principles  of 
architectural  design  and  its  role  within 
the  lifecycle 

Entry 

Activity 

6.0  ARCHITECTUR 

E  DESIGN 

Identify  the  basic  elements/sections  of 
an  Technical  Data  Package  (TDP) 

Entry 

Activity 

10.0  VALIDATION 

Understands  the  purpose  of  validation 

Entry 

Activity 

10.0  VALIDATION 

Understand  structure  and  basic 

elements  of  a  SOVT  document 

Entry 

Activity 

11.0  TRANSITION 

Aware  of  the  type  of  activities  required 
for  transition  to  operation 

Entry 

Activity 

12.0  SYSTEM  ASSU 

RANCE 

Knowledge  of  Risk  Management 
Framework  (RMF) 

Entry 
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Competency 

Vector 

Competency  Area 

KSA 

Stage 

Activity 

12.0  SYSTEM  ASSU 

RANCE 

Knowledge  of  information  assurance 
principles  and  tenets  (confidentiality, 
integrity,  availability,  authentication, 
non-repudiation). 

Entry 

Activity 

15.0  TECHNICAL  P 

LANNING 

Basic  knowledge  of  technical 
disciplines/specialties  applicable  to 
command 

Entry 

Activity 

15.0  TECHNICAL  P 

LANNING 

Knowledge  of  the  command's  global 

WBS 

Intermediate 

Activity 

15.0  TECHNICAL  P 

LANNING 

Able  to  tailor  systems  engineering 
processes  to  meet  the  needs  of  a 
specific  project/program 

Intermediate 

Activity 

15.0  TECHNICAL  P 

LANNING 

Understands  the  importance  of 
planning,  monitoring  and  controlling 
systems  engineering  activities 

Entry 

Activity 

15.0  TECHNICAL  P 

LANNING 

Aware  that  common  technical  processes 
need  to  be  planned 

Entry 

Activity 

16.0  TECHNICAL  A 

SSESSMENT 

Able  to  (for  a  subsystem  or  simple 
project)  monitor  progress  against  plans 

Intermediate 

Activity 

16.0  TECHNICAL  A 

SSESSMENT 

Identifies  continuous  process 
improvements  that  enhance  processes, 
products,  and  service  quality. 

Entry 

Activity 

16.0  TECHNICAL  A 

SSESSMENT 

Aware  of  review  types  and  their 
purposes 

Entry 

Activity 

16.0  TECHNICAL  A 

SSESSMENT 

Aware  of  activities  to  prepare  for 
technical  assessments 

Entry 

Activity 

17.0  CONFIGURAT 

ION  MANAGEMEN 

T 

Knowledge  and  basic  abilities  associated 
to  perform  configuration  management 
activities 

Entry 

Activity 

17.0  CONFIGURAT 

ION  MANAGEMEN 

T 

Aware  of  configuration  change  control 

Entry 

Activity 

18.0  REQUIREMEN 
TS  MANAGEMENT 

Participate  in  (for  a  subsystem  or  simple 
project)  documenting  requirements  in 
the  proper 
format. 

Intermediate 

Activity 

18.0  REQUIREMEN 
TS  MANAGEMENT 

Knowledge  of  the  Engineering  Change 
Proposal  (ECP)  review  process 

Entry 

Activity 

18.0  REQUIREMEN 

TS  MANAGEMENT 

Knowledge  of  requirements 
management  process. 

Entry 
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Competency 

Vector 

Competency  Area 

KSA 

Stage 

Activity 

19.0  RISK  MANAG 

EMENT 

Knowledge  of  and  the  ability  to 
contribute  to  identification  of  risk,  risk 
analysis,  and  risk  monitoring 

Entry 

Activity 

19.0  RISK  MANAG 

EMENT 

Assists  in  executing  the  risk  mitigation 
plan  to  ensure  successful  project  and 
program  completion. 

Entry 

Activity 

20.0  TECHNICAL 

DATA 

Ability  to  document  and  present  lessons 
learned 

Entry 

Activity 

21.0  INTERFACE  M 

ANAGEMENT 

Understands  the  need  for  interface 
management  and  its  impact  on  the 
integrity  of  the  system  solution 

Entry 

Activity 

22.0  SOFTWARE 

ENGINEERING 

Basic  understanding  of  software 
engineering  principles 

Entry 

Activity 

23.0  ACQUISITION 

Ability  to  develop  a  Performance  Work 
Statement  (PWS)  /  Statement  of 
Objectives  (SOO) 

Intermediate 

Activity 

23.0  ACQUISITION 

Provides  information  for  the 

Performance  Work  Statement  (PWS)  / 
Statement  of  Objectives  (SOO) 

Entry 

Activity 

25.0  SYSTEM  OF  S 

YSTEMS 

Understands  that  SoS  capability  needs 
impact  the  system  development 

Entry 

Activity 

30.0  SYSTEMS 

THINKING 

Able  to  describe  the  systems 
engineering  lifecycle  processes  that  are 
in  place  on  their  program 

Intermediate 

Activity 

30.0  SYSTEMS 

THINKING 

Able  to  define  system  boundaries  and 
external  interfaces 

Intermediate 

Activity 

30.0  SYSTEMS 

THINKING 

Aware  of  the  influence  the  system  has 
on  the  enterprise 

Entry 

Activity 

Data  Engineering 

Aware  of  data  management  and  data 
storage  concepts 

Entry 

Activity 

Enterprise 

Architecture 

Understand  the  purpose  and  value  of 
using  architectures  for  requirements 
documentation,  systems  planning  and 
investment  decisions 

Entry 

Activity 

Enterprise 

Architecture 

Knowledge  of  DoD  enterprise 
architecture  principles  and  reference 
models 

Intermediate 

Technology 

Communications 

Basic  knowledge  of  the  characteristics  of 
different  communications  systems 

Entry 

52 


Competency 

Vector 

Competency  Area 

KSA 

Stage 

Technology 

IT  SERVICE 

MANAGEMENT 

Awareness  DoD  and  DON  ITSM  policies, 
guidance  and  core  references 

Entry 

Technology 

Networks 

Knowledge  of  computer  networking 
fundamentals 

Entry 

Mission 

GENERAL 

Basic  understanding  of  all  Mission  Areas 
/  Domains 

Entry 

Table  10.  KSAs  core  to  all  members  of  SSC  Atlantic  Engineering  Department 


C.  SSC  ATLANTIC  ENGINEERING  ROLES 

With  common  KSAs  established  for  all  members  of  the  SSC  Atlantic  Engineering 
Department,  attention  can  now  be  focused  towards  identifying  the  roles  and  subroles  that 
can  be  performed  by  employees  of  the  department.  The  role  of  a  systems  engineer  is  one 
of  many  roles  that  can  be  performed  at  SSC  Atlantic.  As  of  June  2013,  SSC  Atlantic  had 
identified  the  following  roles  to  be  germane  to  the  SSC  Atlantic  Engineering  Department: 

•  Systems  engineer 

•  Technical  specialist 

•  Software  professional 

•  Data  professional 

•  IT  service  management  specialist 

•  Tester 

•  Information  assurance  (IA)  professional 

•  Mission  specialist 

•  Architect  (a.k.a.  enterprise  architect) 

Each  of  the  KSAs  that  are  identified  for  a  systems  engineer  may  also  be  used  for 
other  roles  as  well.  In  other  words,  some  KSAs  may  be  unique  to  a  particular  role, 
whereas  some  KSAs  may  be  common  to  multiple  roles.  Chapter  IV,  Section  B 
highlighted  an  extreme  case  where  certain  KSAs  were  considered  to  be  common  to  all 
roles  and,  therefore,  core  to  all  members  of  the  SSC  Atlantic  Engineering  Department. 
Figure  15  shows  how  the  role  of  a  tester  may  share  some  of  the  basic  KSA  requirements 
as  that  of  a  systems  engineer;  however,  the  tester  role  also  stresses  KSAs  in  the 
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competency  area  of  validation  that  the  basic  systems  engineer  CDM  would  not  include. 
Conversely,  a  systems  engineer  is  expected  to  develop  a  deeper  set  of  KSAs  in  the 
competency  areas  of  requirements  analysis  and  architecture  design  than  the  tester.  A 
complete  description  of  each  of  the  roles  identified  above  can  be  found  in  Appendix  C: 
SSC  Atlantic  Engineering  Department  Role  Descriptions. 
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Figure  15.  Mapping  Roles  to  sets  of  KSAs — Comparing  Systems  Engineering  Role 

to  that  of  a  Tester 


D.  SUBROLES  OF  THE  SSC  ATLANTIC  SYSTEMS  ENGINEER 

Just  as  there  are  KSAs  common  to  all  members  of  the  SSC  Atlantic  Engineering 
Department,  there  are  also  KSAs  common  to  all  Systems  Engineers.  In  May  2013,  SSC 
Atlantic  systems  engineer  “role  champions”  (those  responsible  for  defining  the  KSAs 
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associated  with  the  systems  engineer  role)  identified  KSAs  common  to  all  systems 
engineers  at  various  CDM  stages.  Table  11  depicts  these  core  systems  engineer  KSAs  by 
competency  area. 


Competency 

Vector 

Competency  Area 

KSA 

Stage 

Activity 

1.0  TECHNICAL  BASIS  FOR  COST 

Ability  to  contribute  to 
a  Project  Management 
Plan  (PMP) 

Intermediate 

Activity 

1.0  TECHNICAL  BASIS  FOR  COST 

Ability  to  Review  and 
approve  cost  estimates 
for  subsystem 
elements. 

Intermediate 

Activity 

5.0  REQUIREMENTS  ANALYSIS 

Understands  the 
characteristics  of 
quality  requirements 

Intermediate 

Activity 

5.0  REQUIREMENTS  ANALYSIS 

Prioritizes  requirements 
for  system  upgrades 
and  future 

enhancements  with  the 
sponsor/customers,  key 
stakeholders,  and  end 

users 

Advanced 

Activity 

6.0  ARCHITECTURE  DESIGN 

Facilitates  agreements 
among  multiple 
stakeholders  to  resolve 
system  interfaces  and 
interoperability 

concerns. 

expert 

Activity 

16.0  TECHNICAL  ASSESSMENT 

Executes  continuous 
process  improvements 
that  enhance 
processes,  products, 
and  service  quality. 

Intermediate 

Activity 

17.0  CONFIGURATION  MANAGEMENT 

Basic  ability  to  use 
configuration 
management  tools  for 
configuration 
management 

Entry 

Activity 

19.0  RISK  MANAGEMENT 

Knowledge  of  and  the 
ability  to  contribute  to 
development  of  risk 
mitigation/contingency 
action  plans 

Entry 
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Competency 

Vector 

Competency  Area 

KSA 

Stage 

Activity 

19.0  RISK  MANAGEMENT 

Able  to  perform  risk 
analysis 

Intermediate 

Activity 

23.0  ACQUISITION 

Serve  on  Source 
Evaluation  Board  (SEB) 
or  as  a  Contracting 
Officer's  Representative 
(COR)  and  have 
experience  with 
development  and 
implementation  of 
contracts,  procurement 
of  major  hardware  or 
software  situations 

Intermediate 

Activity 

30.0  SYSTEMS  THINKING 

Able  to  define  technical 
problem  scope 

Intermediate 

Table  11.  KSAs  Common  to  All  Systems  Engineers 


There  are  a  large  number  of  project  types  for  which  a  systems  engineer  at  SSC 
Atlantic  may  be  tasked  to  perform.  Therefore,  there  are  lots  of  different  types  of  systems 
engineers.  While  there  is  a  common  set  of  KSAs  associated  with  systems  engineers, 
there  are  a  number  of  KSAs  that  depend  upon  the  subrole  or  specialty  area  of  the  systems 
engineer.  Figure  16  defines  the  systems  engineer  subroles  or  specialty  areas  critical  to 
the  SSC  Atlantic  Engineering  Department.  Appendix  D  shows  how  role  cards  can  be 
used  to  define  and  communicate  each  of  the  systems  engineer  subroles  or  specialty  areas 
in  terms  of  their  basic  role  description/duties,  key  KSAs,  typical  employee  job  series, 
typical  work  products  or  deliverables,  and  recommended  training. 
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Tester 
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Figure  16.  SSC  Atlantic  Engineering  Department  Roles  / 
Subroles  of  Systems  Engineer 
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E.  SSC  ATLANTIC  SE  USE  CASES 


An  IPT  at  SSC  Atlantic  typically  supports  a  number  of  related  projects.  IPTs  are 
usually  organized  by  common  end  item  products  and/or  funding  sponsors.  For  example, 
an  IPT  may  focus  entirely  on  wireless  communications  for  the  Navy,  electronic  security 
systems  for  the  U.S.  Marine  Corps,  or  command  center  IT  infrastructure  for  Joint 
services.  The  projects  within  an  IPT  may  be  highly  correlated,  where  the  end  item 
product  to  be  delivered  by  each  project  has  a  physical  interface  and  interdependency  with 
the  products  of  the  other  projects.  In  this  case,  the  IPT  may  even  be  delivering  an 
integrated  system  of  systems.  In  other  cases,  projects  within  an  IPT  are  simply  of  a 
similar  nature,  but  do  not  deliver  interfacing  end  item  products.  In  these  cases,  it  is 
commonplace  for  an  IPT  to  specialize  in  a  family  of  systems  that  are  routinely  designed 
and  delivered  to  multiple  locations,  but  in  similar  configurations. 

Given  the  astounding  number  of  IPT  formations,  IT  domains  and  variations  in 
system  (or  end  item  product)  complexity,  it  would  be  very  difficult  to  create  a  framework 
that  satisfies  all  potential  systems  engineering  use  cases  in  full.  However,  by 
generalizing  most  of  SSC  Atlantic’s  SE  projects  into  five  different  use  cases,  one  can 
understand  some  of  the  more  common  IPT  perspectives  on  the  role  of  a  systems  engineer. 
The  following  subsections  examine  these  five  use  cases  and  some  of  their  key 
competency  areas.  The  figures  provided  with  each  of  these  use  cases  were  developed  in 
collaboration  with  John  Lillard,  SSC  Atlantic  Information  Dominance  Chief  Architect. 
These  images  were  used  to  help  clarify  various  levels  of  abstraction  in  system  complexity 
and  SE  project  types. 

1.  SE  Use  Case  1 — Subsystem  or  Component  Engineering  and 
Assessments 

In  this  scenario,  the  project  scope  for  an  IPT  would  be  to  develop,  procure  or 
assess  a  new  component  or  subsystem  for  use  within  a  larger  system.  The  engineering  of 
the  overall  system  is  managed  outside  of  the  IPT’s  project  scope.  An  example  would  be  a 
biometrics  IPT  which  is  tasked  to  assess  facial  recognition  technologies  to  determine 
which  one  will  provide  the  highest  quality  solution  to  meet  the  customer’s  needs  at  the 
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best  value  to  the  government.  Key  competency  areas  associated  with  this  use  case 
include  decision  analysis  as  well  as  any  number  of  competency  areas  within  the 
technology  competency  vector  (for  example,  sensors.) 
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Figure  17.  SE  Use  Case  1 — Subsystem  or  Component  Engineering  and  Assessments 

2.  SE  Use  Case  2 — Systems  Engineering  (Simple  System) 

In  this  scenario,  an  SSC  Atlantic  IPT  would  be  tasked  to  develop  and/or  integrate 
a  new  capability  in  the  form  of  a  system,  which  is  comprised  of  commercial-off-the-shelf 
(COTS)  and/or  government-off-the-shelf  (GOTS)  components  integrated  into  a  single 
capability.  This  type  of  system  is  typically  used  by  a  single  organization  or  single 
mission.  Key  competency  areas  for  this  use  case  include  stakeholder  requirements 
definition,  architecture  design,  verification  and  transition. 


Figure  18.  SE  Use  Case  2 — Systems  Engineering  (Simple  System) 
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3.  SE  Use  Case  3 — Complex  Systems  Engineering 

Oftentimes,  SSC  Atlantic  is  tasked  with  fulfilling  a  customer  capability  gap  that  is 
more  complex  in  nature  and  the  basic  problem  at  hand  has  not  been  solved  in  the  past.  In 
this  case,  SSC  Atlantic  may  be  tasked  with  developing  and/or  integrating  a  new 
capability  in  the  form  of  a  system.  The  scale  of  the  system,  its  functions  and  interactions 
along  with  the  diversity  of  the  user  base  elevate  the  complexity  of  the  effort.  The 
resulting  system  is  comprised  of  COTS  and  or  GOTS  components  integrated  into  a  large, 
multifunction  capability.  Key  competency  areas  associated  with  complex  systems 
engineering  include  requirements  management,  risk  management,  interface  management, 
and  integration. 


Figure  19.  SE  Use  Case  3 — Complex  Systems  Engineering 


System  complexity  plays  a  key  role  in  delineating  between  SE  Use  Case  2  and  3. 
Table  1 1  depicts  the  key  differences  between  basic  or  simple  systems  engineering  and 
complex  systems  engineering  as  they  apply  to  SSC  Atlantic  IT  projects. 
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▼  Basic  Systems  Engineering 
■  Project  Scope: 

•  Standard  design  already  exists 

■  Systems  Engineering  effort 
only  requires  minor  tailoring 
of  design 

*  System  Complexity: 

■  Smalt  #  of  components 

■  Few  interactions  b/t 
components 

■  System  will  not  evolve  over 
time 

»  Minimal  to  no  external  system 
interfaces 

■  Singular  user  base 

■  Focus  is  on  a  specific 
tech  no  logy/product 

*  Single  protocol 


▼  Complex  System  Engineering 

■  Project  Scope: 

■  Requirements  for  a  new  or 
significantly  upgraded 
capability  exists 

■  No  standard  design  already 
exists 

■  System  Complexity: 

■  Large  H  of  components  with 
many  interactions  b/t 
components 

“  System  will  evolve  over  time 

•  At  least  one  external  interface 
-  Multiple  &  diverse 

sta  keholders 

*  Focus  on  design/integration  of 
multiple 

technologies/prod  ucts 

■  Includes  multiple  protocols  to 
ensure  dissemination  and 
receipt  of  info 


Figure  20.  Comparison  of  Basic  (Simple)  SE  and  Complex  SE 


4.  SE  Use  Case  4 — Platform  Systems  Engineering 

The  SE  use  case  for  platform  systems  engineering  focuses  on  the  integration  of 
systems  into  physical  platforms  to  ensure  that  environmental,  mounting,  heat,  power, 
lighting,  network  infrastructure,  safety,  ergonomics  and/or  survivability  requirements  are 
met.  Physical  platforms  may  include  vehicles,  ships,  submarines,  buildings,  command 
centers  and  other  physical  structures  in  which  IT  systems  and  infrastructure  may  be 
integrated.  This  use  case  stresses  the  conduct  of  site  or  platform  surveys  (part  of 
technical  assessment),  technical  data  package  development  (part  of  architecture  design), 
technical  planning,  integration,  validation  and  safety  assurance. 
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Platform 


Figure  21.  SE  Use  Case  4 — Platform  Systems  Engineering 


5.  SE  Use  Case  5 — Systems  of  Systems  (SoS)  Engineering 

Some  of  the  IPT  efforts  at  SSC  Atlantic  are  more  focused  on  the  methodology  of 
systems  of  systems  engineering  rather  than  on  the  life  cycle  processes  of  conventional 
systems  engineering.  SoS  engineering  focuses  on  the  planning,  analyzing,  organizing, 
and  integrating  of  capabilities  from  a  mix  of  existing  and  new  IT  systems  into  an  SoS 
capability  greater  than  the  sum  of  the  capabilities  of  the  constituent  parts.  In  addition  to 
the  tenets  of  traditional  systems  engineering,  SoS  engineering  manages  the  complexity 
created  by  the  cost,  schedule  and  performance  interdependencies  of  multiple  independent 
programs  that  comprise  the  SoS.  SoS  engineering  efforts  are  heavily  grounded  in  the 
competency  areas  of  systems  thinking,  enterprise  architecture,  interface  management,  risk 
management  and,  of  course,  SoS  engineering. 
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Figure  22.  SE  Use  Case  5 — Systems  of  Systems  Engineering 

F.  COMPETENCY  DEVELOPMENT  AND  ITS  RELATIONSHIP  TO 
SYSTEM  COMPLEXITY 

Over  the  course  of  his  or  her  career,  a  systems  engineer  will  likely  encounter 
projects  that  span  more  than  one  of  the  SE  use  cases  described  in  Chapter  IV,  Section  E. 
For  example,  a  systems  engineer  may  start  out  researching  and  assessing  various  IT 
components,  then  take  on  an  assignment  as  a  project  engineer  for  a  simple  system,  then 
grow  into  the  role  of  a  lead  systems  engineer  for  a  complex  system,  and  so  forth. 
Generally  speaking,  a  systems  engineer  will  be  assigned  tasking  that  increases  in  system 
complexity  over  time.  Not  coincidentally,  a  systems  engineer  will  develop  KSAs  across 
higher  proficiency  or  developmental  levels.  This  increase  in  competency  and  increased 
responsibility  with  more  complex  systems  and  projects  go  hand  in  hand.  Figure  23  from 
Building  a  Competency  Taxonomy  to  Guide  Experience  Acceleration  of  Lead  Program 
Systems  Engineers  illustrates  the  notional  progress  a  systems  engineer  would  exhibit  over 
the  course  of  his  or  her  career  in  terms  of  increased  proficiency/competency  and  the 
responsibility  of  addressing  situations  and  systems  of  increasing  complexity. 
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Proficiency  Level 


Situation 

Complexity 


None  or 
Aware 
Only 


Exceptionally 

Complex 


C  onsiderably 
Complex 


Complex 


Somewhat 

Complex 


Apply 

with 

Guidance 


Apply 


Manage 
or  Lead 


Advance 
State  of 
Art 


Simple 


Figure  23.  Proficiency  Level  and  Situational  Complexity 
(From  Squires  et  al.,  201 1,  p.  7) 


Chapter  IV,  Section  D  defined  several  subroles  for  the  role  of  a  systems  engineer. 
Each  of  these  subroles  bears  its  own  set  of  KSAs  at  various  proficiency  stages  and 
therefore,  its  own  competency  development  model.  Figure  24  depicts  competency 
development  progression  for  four  subroles  of  the  SE  role — platform,  communications, 
networks  and  technical  management.  This  figure  was  developed  in  collaboration  with 
John  Lillard  (SSC  Atlantic)  in  order  to  illustrate  how  a  SE  competency  development 
model  provides  a  developmental  roadmap  for  systems  engineers  in  terms  of 
competency/proficiency  progression,  increased  project  or  system  complexity  and 
increased  leadership  responsibility. 
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Sys  Engineer 
(Platform) 


Sys  Engineer 
(Comma) 


Sys  Engineer 
(Networks) 


Sys  Engineer 
(Tech  Mgt) 


Hsrr1 

Performs  engineering 

with  little  to  no 

Platform 

assistance 

Engineer 

♦ 

Assists  in 
execution  of 
erg  i  peering 


Lead  Network 
Engineer 


Network 

Engineer 


Associate 
Communications 
Systems  Engineer 


Associate 

Network 

Engineer 


Senior 

Systems 

Engineer 


Systems 

Engineer 


Associate 

Systems 

Engineer 


Progression  through  development  and  increased  responsibility 


Figure  24.  Competency  Development  /  Proficiency  Progression  for  Sub-roles  of  a 

Systems  Engineer 
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V.  A  MODEL  FOR  EFFECTIVE  SYSTEMS  ENGINEERING 
WORKFORCE  DEVELOPMENT  AT  SSC  ATLANTIC 

A.  EMPLOYING  COMPETENCY  DEVELOPMENT  MODELS 

Defining  the  competency  areas  and  KSAs  required  for  SSC  Atlantic  systems 
engineers  at  various  competency  development  levels  and  different  use  cases  explains 
what  types  of  KSAs  need  to  be  developed.  However,  if  a  systems  engineer  determines 
that  he  or  she  has  a  gap  in  KSAs  in  order  to  achieve  his  or  her  goals,  then  the  competency 
framework  can  only  tell  them  what  the  systems  engineer  is  missing.  In  order  to 
adequately  employ  a  competency  development  model,  one  must  recommend  how  KSAs 
can  or  even  should  be  obtained. 

According  to  the  naval  SE  CDM,  KSAs  can  principally  be  obtained  through  the 
following  developmental  methods: 

•  Education — Learned  in  a  classroom  environment  as  part  of  undergraduate, 
graduate  or  certificate  programs 

•  On  the  job  training — Learned  on  the  job 

•  Professional  development — Workshops  or  training  sessions  accomplished 
within  an  organization 

Using  the  basic  KSA  development  methods  defined  by  the  naval  SE  CDM,  four 
primary  methods  can  be  applied  to  SSC  Atlantic: 

•  Defense  Acquisition  University  courses  (educational  training) 

•  Graduate  or  certificate  program  (educational  training) 

•  SSC  Atlantic-developed  and  provided  training  courses  and/or  workshops 
(professional  development) 

•  On  the  job  training 

In  an  Internet  post  entitled  “Education  versus  Training,”  Geetha  Krishnan  (2008) 
makes  the  following  assertions  that  help  differentiate  education  (educational  training) 
from  training  (professional  development): 
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Education  emphasizes  first  principles;  training  emphasizes  application. 
Education  focuses  on  building  the  mind;  training  on  building  skills. 


Most  training  is  communication;  hence  the  pizzazz.  Presentation  style  is 
more  important  than  instructional  rigor.  Education,  for  the  most  part  (refer 
the  parenthetical  point  on  the  social  act  above),  is  content-driven. 

Most  training  is  company-specific;  hence,  not  easily  transferable  from  one 
job  to  another.  Most  education  would  be  transferable. 

The  learner  for  both  education  and  training  could  be  unwilling.  But  the 
learner  for  training  is  allowed  to  voice  his  thoughts  and  get  the  training  / 
trainer  changed.  The  onus  of  making  training  succeed  is  on  the  trainer  or 
the  organization;  in  education  the  learner  takes  a  higher  responsibility.  As 
a  corollary,  if  you  don’t  do  well  in  education,  you  fail;  if  you  don’t  do  well 
in  training,  the  training  failed  (Krishnan,  2008). 

Each  of  these  assertions  may  be,  in  fact,  matters  of  Krishnan’s  opinion;  however, 
when  the  term  “education”  is  replaced  with  “educational  training”  meaning 
undergraduate,  graduate  or  certificate  programs,  then  many  analogies  can  be  made.  For 
example,  SE  graduate  degree  programs  and  the  Certified  Systems  Engineering 
Professional  (CSEP)  certification  emphasize  the  principles,  focus  on  SE  process  life  cycle 
content,  and  are  transferable  to  a  wide  range  of  Industry  and  DoD  organizations.  When 
the  term  “training”  is  replaced  with  “professional  development”  or  training/workshops 
accomplished  within  an  organization  such  as  SSC  Atlantic,  then  similar  analogies  can  be 
made.  Generally  speaking,  SSC  Atlantic-developed  and  delivered  SE  training  is 
organization-specific,  is  not  as  easily  transferable  from  one  organization  to  another, 
emphasizes  the  application  of  SE  principles,  and  generally  offers  a  more  dynamic 
opportunity  for  feedback  to  the  training  instructor  who  is  likely  a  practicing  systems 
engineer  moonlighting  as  a  trainer. 
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B.  THE  ROLE  OF  DEFENSE  ACQUISITION  UNIVERSITY  IN  SE 

WORKFORCE  DEVELOPMENT 

Most  systems  engineers  at  SSC  Atlantic  are  either  designated  as  being  in  a 
Defense  Acquisition  Workforce  Improvement  Act  (DAWIA)  Systems  Planning, 
Research,  Development  and  Engineering  (SPRDE)-SE  billet  or  have  at  least  taken  some 
of  the  associated  DAU  classes  covered  by  the  SPRDE-SE  curriculum.  The  SPRDE-SE 
classes  are  a  combination  of  computer-based  and  instructor-led  training.  Figure  25  shows 
a  breakdown  of  the  primary  SPRDE-SE  classes  and  the  percentage  of  the  learning 
objectives  associated  with  each  level  of  Bloom’s  taxonomy  (discussed  in  Chapter  III).  In 
this  case,  learning  objectives  are  directly  correlated  to  the  KSAs  that  are  targeted  to  be 
developed  by  each  class.  The  far  right  column  of  Figure  25  shows  what  percentage  of  the 
naval  SE  CDM  (shown  here  as  the  NPS  SE  COMP  MOD)  KSAs  are  associated  with  each 
level  of  Bloom’s  taxonomy  as  well.  Figure  25  illustrates  that,  in  general,  DAU  covers  the 
knowledge  and  comprehension  levels  of  Bloom’s  taxonomy  sufficiently.  Therefore,  for 
KSAs  that  are  associated  with  basic  DoD-generic  (as  opposed  to  SSC  Atlantic-specific) 
knowledge  and  comprehension,  it  makes  sense  for  DAU  training  to  be  the  preferred  KSA 
development  method. 
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Figure  25.  Cognitive  Levels  of  DAU  SPRDE-SE  Level  III  Curriculum  and  NPS  SE 

Competency  Model  (From  Alexander,  2013,  p.  42) 


It  would  be  insufficient  to  look  solely  at  the  level  of  Bloom’s  taxonomy  when 
assessing  the  applicability  of  DAU  classes  to  SE  KSAs.  One  must  also  analyze  the 
respective  competency  areas  emphasized  in  the  DAU  SPRDE-SE  classes  to  determine 
which  are  adequately  addressed  and  which  are  not.  Figure  26  depicts  the  number  of 
DAU  SPRDE-SE  continuous  leaming/performance  objectives  (CL/POs)  associated  with 
each  SE  competency  area.  It  should  be  noted  that  the  competency  areas  of  acquisition 
and  risk  management  are  appropriately  covered  by  SPRDE-SE.  In  fact,  Juli  Alexander 
observes,  “the  DAU  SPRDE-SE  training  curriculum  is  robust  with  regard  to  acquisition 
training.  Approximately  a  third  of  the  curriculum  focuses  on  this  essential  competency” 
(2013,  p.  xvi).  Technical  planning  in  a  broad  sense  is  sufficiently  covered  as  well,  but 
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likely  requires  tailoring  to  show  how  it  should  be  accomplished  within  an  organization 
such  as  SSC  Atlantic.  Alexander  also  points  out  that  the  competency  areas  for  safety 
assurance,  system  assurance,  systems  of  systems,  problem  solving  and  strategic  thinking 
show  no  “evidence  of  a  strong  link  between  the  curriculum  and  the  competency  model. . . 
This  would  strongly  demonstrate  that  the  competencies  in  the  model  are  not  being 
addressed  by  the  DAU  SPRDE  training  curriculum”  (2013,  p.  53).  It  should  also  be 
noted  that  neither  the  technology  nor  the  mission  competency  vectors  are  covered  in 
SPRDE-SE.  That  being  said,  DAU  offers  a  variety  of  SE  classes  in  areas  such  as  systems 
of  systems,  system  assurance  and  other  SE  competency  areas  that  are  available  DoD- 
wide  but  simply  not  included  as  part  of  the  SPRDE-SE  career  track. 
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Figure  26.  Number  of  DAU  SPRDE-SE  CL/POs  in  Each  Systems  Engineering 

Competency  (From  Alexander,  2013,  p.  46) 
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C.  IN-HOUSE  SE  TRAINING  CURRICULUM  DEVELOPMENT 

When  it  comes  to  optimal  methods  for  KSA  development,  the  SEBoK  states  that, 
“traditionally,  SE  competencies  have  been  developed  primarily  through  experience,  but 
recently,  education  and  training  have  taken  on  a  much  greater  role”  (Pyster  et  al.,  2012, 
p.  694).  DAU  provides  SE  and  acquisition  training  to  all  of  the  DoD;  therefore,  much  of 
the  associated  course  material  must  be  tailored  for  implementation  at  each  DoD 
organization  such  as  SSC  Atlantic.  For  example,  a  SPRDE-SE  class  may  provide  the 
participant  with  knowledge  regarding  the  key  attributes  of  a  sound  requirement. 
However,  that  class  will  not  specify  which  requirements  management  tools  are  to  be  used 
by  the  individual  organizations,  nor  how  specific  requirements  should  be  captured  or 
documented.  There  are  many  cases  such  as  this  where  the  organization  performing  the 
work  must  develop  or  tailor  its  own  SE  classes  in  order  to  train  the  workforce  on  just  how 
to  execute  these  processes  in  a  consistent  manner.  Systems  engineers  should  also  be 
educated  on  the  specific  SE  tools  used  by  their  individual  organizations.  Examples  of 
such  tools  include  those  associated  with  configuration  management,  risk  management, 
requirements  management  and  architecture  design. 

The  other  major  gap  between  what  DAU  has  to  offer  and  the  SSC  Atlantic 
competency  framework  KSAs  lies  in  the  technology  competency  areas.  Since  SSC 
Atlantic  is  an  IT-centric  command,  networks,  software  applications,  sensors  and  other 
technology  areas  must  be  well  understood  by  its  systems  engineers.  This  training  gap 
also  points  to  the  need  to  provide  command-specific  training.  In  the  SSC  Atlantic 
networks  and  communications  department,  senior  leaders  have  already  begun  developing 
“Network  University”  classes  in  order  to  educate  systems  engineers  (with  a  networks 
subrole/specialty)  on  the  basics  of  Navy  network  architecture  design. 

So  how  does  one  go  about  developing  an  “in-house”  SE  curriculum  to  address 
workforce/KSA  development  needs?  GRCSE  provides  a  process  script  for  developing  a 
curriculum  for  any  competency,  as  shown  in  Table  12.  From  the  steps  highlighted  in 
Table  12,  a  tailored  SE  curriculum  development  process  for  SSC  Atlantic  can  be 
established.  This  approach  would  be  considered  a  holistic  approach  to  SE  curriculum 
development. 
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1.  Holistic  Approach  to  SE  Curriculum  Development 

•  Step  1:  Establish  SSC  Atlantic  SE  competency  framework  (the  analysis  of 
existing  competency  models,  prioritization  of  relevant 
competencies/KSAs,  and  defining  proficiency  levels/stages  from  Table  12 
Step  2) 

•  Step  2:  Prepare  outcomes  and  objectives  that  align  to  the  SSC  Atlantic 
engineering  process  framework  (this  step  tailored  from  Table  12  Step  3 
Bullet  1) 

•  Step  3:  Use  outcomes  and  objectives  to  prepare  SE  curriculum  in  4  basic 
modules: 

•  Technical  Management 

•  System  Design 

•  Product  Realization 

•  Technologies  &  Missions 


Process  Step 

Description 

Step  1:  Establish  the 
Development  Team 

*  Identify  program  stakeholders 

*  Form  team  from  stakeholders  such  as  faculty  responsible  for  curriculum 
design  and  representatives  from  prospective  employing  organizations. 

*  Use  a  wide  group  of  reviewers  for  each  stage  of  development. 

Step  2:  Create 
Competency  Model 

*  Study  and  a nalyze  va nous  competency  models. 

*  Choose  or  adapt  competencies  appropriate  to  the  stakeholders. 

*  Define  proficiency  levels. 

*  Select  target  proficiency  levels  for  each  competency. 

Step  3:  Prepare  Draft 
Curriculum 

•  Based  on  competency  model,  prepare  draft  outcomes  and  objectives. 

*  Use  outcomes  and  objectives  to  prepare  a  draft  curriculum. 

Step  4:  Assess  Draft 
Curriculum  against 
Competency  Model 

*  For  each  competency,  identify  where  in  the  curriculum  it  Is  addressed  and 
assess  its  summative  proficiency  level. 

*  Aggregate  and  report  on  gaps  between  the  "as  is"  and  "to  be"  proficiency 
levels.  Also,  report  on  problems  with  the  competency  model  (e.g., 
imprecise  descriptions  of  proficiency  levels). 

Step  5:  Evolve 
Curriculum  and 
Competency  Model 

*  Based  on  the  competency  assessment  report,  identify  curriculum 
elements  that  appear  weak  (e.g.,  entrance  expectations,  outcomes, 
objectives,  curriculum  architecture,  the  CorBoK,  or  individual  course 
activities. 

*  Determine  required  changes  in  the  curriculum  and  implement  them. 

*  Modify  the  competency  model  based  on  the  competency  assessment 
report. 

*  Repeat  steps  4  and  5  after  implementation  to  ensure  continual  evolution 
and  improvement  of  the  curriculum. 

Figure  27.  Process  Script  for  Competency-based  Curriculum  Development. 

(From  GRCSE  vl.O,  2012,  p.  109) 
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Taking  a  holistic  or  “top-down”  approach  can  be  effective  in  ensuring  the  breadth 
of  competency  area  and  KSA  coverage  in  an  in-house  SE  curriculum.  However,  the 
voice  of  the  systems  engineering  workforce  must  also  be  truly  heard  in  order  to  for  the 
training  strategy  to  be  optimally  effective.  Once  a  holistic  SE  curriculum  development 
strategy  is  established  as  summarized  above,  then  a  more  grassroots  approach  should  be 
taken  to  truly  understand  where  SE  skills  have  the  greatest  gap  between  supply  and 
demand. 

2.  Bottom-Up  Approach  to  SE  Curriculum  Development 

•  Step  1:  Observe  where  employees  lack  knowledge  of  SE  competency 
areas 

•  Step  2:  Generate  training  concepts  to  fill  gaps 

•  Step  3:  Survey  workforce  to  determine  where  training  is  most  needed 

•  Step  4:  Research  what  classes  DAU,  SSC  Pacific  and  others  have  to  offer 

•  Step  5:  Decide  which  training  classes  need  to  be  developed  or  tailored 

•  Step  6:  Use  various  SE  forums,  blogs  and  wikis  to  shape  class  learning 
objectives  with  participation  from  the  SE  workforce 

•  Step  7:  Recruit  coalition  of  the  willing  and  capable  to  develop  and  deliver 
training 

•  Step  8:  Pilot  training  class  exercises  and  draft  training  material  via 
informal  forum  events 

•  Step  9:  Develop  final  training  content  and  aids  (templates,  checklists, 
process  models) 

•  Step  10:  The  willing  and  capable  deliver  training  (then  obtain  feedback 
and  recalibrate) 

When  developing  and  delivering  in-house  training  classes,  here  are  a  few  training 
tips  that  have  proven  effective  when  delivering  basic  SE  training  classes  at  SSC  Atlantic: 

•  Digital  response  technology  using  radio  frequency  (RF)  clickers  can  be 
used  to  gage  audience  understanding  of  key  concepts  throughout  the  class. 
Questions  should  be  challenging  and  generate  thoughtful  discussion  on 
key  concepts. 

•  Well-tailored  individual  and  group  exercises  should  be  leveraged  to  ensure 
employees  know  how  to  apply  key  concepts. 
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•  Defense  Connect  Online  or  other  means  of  web-conferencing  should  be 
used  to  promote  remote  participation,  collaborative  exercises,  polling,  file 
sharing  and  class  recordings. 

•  “Easy”  slides  can  be  included  in  the  training  material  to  help  employees 
gain  course  credit  and  professional  development  units  or  continuous 
learning  points  for  continuing  education. 

One  final  recommendation  for  the  development  and  delivery  of  SE  training 
courses  is  that  the  actual  trainers  should  be  practicing  systems  engineers  themselves. 
Benefits  of  SE  leaders  developing  SE  course  content  and  performing  as  SE  trainers 
include  the  following: 

•  Promotes  knowledge  sharing  and  collaboration 

•  Provides  ample  opportunities  for  natural  leaders  to  step  up 

•  Allows  trainers  to  gain  double  continuous  learning  points  (CLPs) 

•  Typically  results  in  cost  savings  over  vendor-provided  training 

•  Tailors  training  classes  toward  “how  SSC  Atlantic  does  it” 

•  Enables  government  control  over  course  material 

•  Sets  distinct  expectations  for  the  audience  that  can  be  enforced  by  SE 
management 

•  Promotes  environment  of  continual  learning 

•  Enables  rapid  delivery  of  emergent  processes  and  techniques 

•  Allows  trainers  to  truly  master  topics  by  teaching  them 

D.  DEVELOPING  KSAS  THROUGH  OJT  AND  FORMAL  EDUCATION 

Arguably,  the  best  way  to  learn  or  develop  KSAs  is  by  doing.  For  that  reason, 
OJT  is  ideal  when  it  is  possible  and  consists  of  a  more  knowledgeable,  skilled  and 
experienced  systems  engineer  walking  a  less  developed  systems  engineer  through  the 
execution  of  actual  systems  engineering.  For  this  reason,  SSC  Atlantic  has  established 
formalized  programs  to  encourage  this  type  of  knowledge  transfer.  During  their  first  two 
years  of  employment  at  SSC  Atlantic,  junior  systems  engineers  entering  the  workforce 
are  encouraged  to  participate  in  rotational  assignments  on  the  order  of  three  to  six 
months,  and  these  are  designed  to  allow  them  to  learn  from  more  experienced  systems 
engineers  as  well  as  provide  worthwhile  contributions  to  the  associated  projects  and  IPTs 
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More  recently,  SSC  Atlantic  has  also  started  a  job-shadowing  program  in  which 
employees  (not  just  systems  engineers)  can  elect  to  shadow  another  senior  employee  for 
up  to  16  hours  in  order  for  them  to  see  how  that  individual  approaches  his  or  her  job. 
This  allows  for  employees  at  any  point  in  their  career  to  catch  a  glimpse  at  what  it  takes 
to  perform  in  other  positions  within  the  organization  as  well  as  to  get  a  better  feel  for 
which  types  of  positions/jobs  they  might  want  to  pursue  later  in  their  careers.  They  may 
also  find  that  their  “dream  job”  is  not  what  they  truly  desire  and  thus  allows  them  to  more 
quickly  adjust  career  goals  to  where  their  true  passions  can  better  align  with 
organizational  needs. 

A  postgraduate  degree  in  SE  can  significantly  increase  SE  an  individual’s 
competency  level.  Assuming  that  the  employing  organization  will  pay  for  at  least  a 
significant  portion  of  the  postgraduate  degree  cost,  there  are  many  factors  to  consider 
when  an  organization  chooses  to  make  such  an  investment.  Typical  SE  Master’s  degree 
program  costs  are  in  the  $20,000  to  $50,000  range,  but  can  certainly  cost  significantly 
more  or  a  little  less.  Without  question,  cost  should  be  a  major  driving  factor  for  an 
organization  choosing  to  invest  in  a  postgraduate  degree  program  as  there  would  be  an 
advantage  in  affording  to  send  two  individuals  through  a  degree  program  rather  than  one. 
The  use  of  a  cohort,  in  which  several  individuals  from  the  same  organization  participate 
in  the  same  degree  program  for  a  reduced  cost,  should  also  be  encouraged.  Cohorts  also 
offer  students/employees  an  opportunity  to  collaborate  with  one  another  within  the  same 
organization,  which  can  add  value  and  support  to  their  experiences.  In  some  cases, 
cohorts  offer  an  additional  opportunity  for  an  organization  such  as  SSC  Atlantic  (or  its 
Echelon  III  parent  command — Space  and  Naval  Warfare  Command)  the  opportunity  to 
more  significantly  influence  the  scope  of  the  classes  offered  in  the  program  and/or  the 
case  study  or  thesis  topics  available  to  the  students. 

Other  critical  factors  influencing  the  selection  of  a  SE  degree  program  include 
scope  and  timing.  A  SE  degree  program  should  be  selected  which  applies  most  directly 
to  the  scope  of  SE  work  being  conducted  within  the  organization  as  well  as  by  the 
participating  employees.  In  the  case  of  SSC  Atlantic,  a  degree  program  which  features  a 
focus  on  IT  and  naval  systems  would  be  more  valuable  than  one  that  does  not  emphasize 
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these  core  elements  of  SSC  Atlantic’s  mission.  Another  critical  factor  for  SE  degree 
program  selection  is  when  the  individual  embarks  on  this  effort  during  their  career. 
GRCSE  states,  “Whether  the  student  obtains  work  experience  between  completing  a 
bachelor’s  program  and  commencing  master’s  level  studies  is  one  of  the  most  important 
factors  in  professional  master’s  level  study”  (GRCSE,  2012,  p.  5).  With  respect  to 
practicing  systems  engineers  in  the  US  and  in  Europe,  GRCSE  also  points  out  that,  “Few 
obtain  an  undergraduate  SE  degree  or  study  SE  for  their  first  master’s  degree”  (GRCSE, 
2012,  p.  5).  GRCSE  goes  on  to  recommend  that  at  least  two  years  of  professional 
experience  be  obtained  prior  to  pursuit  of  a  master’s  degree  in  SE.  SSC  Atlantic  typically 
requires  five  years  of  professional  experience  as  well  as  achievement  of  the  target 
DAWIA  certification  level  (for  those  in  a  DAWIA  billet)  prior  to  pursuit  of  a 
postgraduate  degree  funded  by  the  organization.  Other  considerations  for  matching 
individuals  with  postgraduate  SE  degrees  include  the  individual’s  likelihood  of  remaining 
in  the  organization  for  a  significant  period  of  time,  probability  of  the  individual  actually 
completing  the  graduate  degree  program,  and  the  probability  that  the  individual  will 
actually  apply  what  is  learned  to  current  and  future  projects. 

E.  OTHER  FORMS  OF  WORKFORCE  DEVELOPMENT  AND  THE 

DEVELOPMENT  OF  LEADERSHIP  SKILLS 

Job  shadowing  and  rotational  opportunities  are  two  of  the  many  opportunities  for 
competency  development  within  SSC  Atlantic.  When  it  comes  to  developing  leadership 
skills  such  as  external  awareness,  interpersonal  skills  and  team  building,  programs  such 
as  the  SSC  Atlantic  Mentorship  Program  and  the  Mid-Career  Leadership  Program 
(MCLP)  can  be  very  effective.  The  Mentorship  Program  offers  a  variety  of  different 
mentor-mentee  engagement  constructs — group  mentoring  (two  mentors  and  eight 
mentees  interacting  at  once),  speed-mentoring  (much  like  speed-dating)  and  classical 
one-on-one  mentoring.  As  of  July  2013,  the  Mentorship  Program  is  in  its  second 
iteration  of  existence  and  continues  to  improve  by  providing  a  loosely-structured,  yet 
objective-driven  roadmap  to  fostering  mentor-mentee  relationships.  The  Mentorship 
Program  is  completely  voluntary  and  allows  mentor-mentee  relationships  to  take  form 
naturally. 
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The  MCLP  offers  a  much  more  intensive  and  structured  learning  environment  for 
SSC  Atlantic  employees  and,  thus,  it  is  much  more  competitive  and  time-consuming. 
The  program  lasts  six  months  and  only  admits  20  participants  each  round.  While  the 
MCLP  does  not  guarantee  promotion,  graduates  are  prepared  to  assume  greater 
leadership  roles  and  responsibilities.  Many  of  the  leadership  skills  highlighted  in  the  SSC 
Atlantic  competency  framework  are  either  directly  or  indirectly  addressed  by  the 
program. 

F.  IDENTIFYING  WORKFORCE  DEVELOPMENT  METHODS  FOR  EACH 
KSA 

Figure  28  provides  a  decision  tree  which  provides  a  recommended  development 
method  for  different  types  of  systems  engineer  KSAs.  Although  no  distinction  was  made 
between  basic  and  advanced  in-house  training,  the  assumption  is  that  a  basic  in-house 
training  session  on  a  given  competency  area  or  set  of  KSAs  would  last  four  to  eight  hours 
with  simple  exercises,  while  a  more  advanced  in-house  training  session  would  generally 
last  forty  hours  or  longer  and  would  include  more  extensive  “real-world”  exercises. 
Appendix  E  provides  recommended  KSA  development  methods  for  each  of  the  KSAs 
identified  for  a  systems  engineer.  The  leadership  skills  are  excluded  from  this  table,  but 
are  included  in  Appendix  B. 


77 


Need 

KSAs 

(START) 


Figure  28.  Decision  Tree  for  Determining  Which  Developmental  Method  Should  Be 

Used  for  Different  Types  of  KSAs 


G.  ASSESSING  A  SYSTEMS  ENGINEER’S  COMPETENCY  LEVEL 

There  are  a  variety  of  ways  to  assess  whether  a  systems  engineer  has  actually 
developed  or  attained  a  particular  knowledge,  skill  or  ability.  The  same  can  be  said  for 
assessment  methods  used  as  exit  criteria  for  passing  SE  courses,  since  the  intent  of  a  SE 
course  is  to  develop  the  KSAs  of  the  participants.  Some  KSA  assessment  methods  are 
very  basic,  easy  to  measure  and  only  provide  limited  insight  into  the  systems  engineer’s 
true  competency,  such  as  the  use  of  multiple-choice  tests.  Other  assessment  methods 
such  as  case  study  projects,  oral  exams  or  written  essays  are  typically  more  labor- 
intensive  and  more  subjective,  yet  offer  additional  insight  into  an  individual’s  depth  of 
KSAs.  GRCSE  Appendix  E  provides  a  more  exhaustive  look  into  conducting  an 
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assessment  of  SE  KSAs  and  course  learning  objectives  (GRCSE,  2012,  p.  97).  As  of  July 
2013,  a  proposal  has  been  set  forth  to  adopt  a  common  competency  development  model 
assessment  process  across  all  of  SSC  Atlantic.  This  competency  assessment  process 
consists  of  individual’s  assessing  themselves  against  their  role’s  competency 
development  model  (CDM),  submitting  their  CDM  self-assessment  and  requested 
development/proficiency  stage  for  official  review,  and  a  competency  assessment  board 
making  the  determination  as  to  whether  or  not  the  individual  has  or  has  not  achieved  their 
asserted  development/proficiency  stage.  If  the  board  determines  that  the  individual  has 
not  achieved  their  desired  stage,  then  the  board  provides  feedback  to  the  employee  as  to 
which  KSAs  require  additional  development  and  basic  recommendations  on  how  to  do 
so.  Figure  29  depicts  the  proposed  SSC  Atlantic  competency  level  assessment  process  as 
illustrated  by  Ann  Rideout,  Deputy  Competency  Lead  for  the  SSC  Atlantic  Networks  and 
Communications  Engineering  Department. 
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Figure  29.  Competency  Level  Assessment  Process 
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VI.  CONCLUSION  AND  RECOMMENDATIONS 


A.  FINDINGS 

Research  question  1  asks  what  competency  areas  and  associated  KSAs  are 
particularly  applicable  to  SSC  Atlantic  systems  engineers.  In  order  to  organize 
competency  areas  and  KSAs  into  logical  groupings,  four  competency  vectors  were 
established  as  depicted  in  Figure  12.  Competency  areas  could  then  be  defined  and 
grouped  under  each  competency  vector.  Each  competency  area  could  then  be  prioritized 
based  on  a  standard  set  of  SE  use  cases  most  commonly  experienced  at  SSC  Atlantic,  as 
well  as  based  on  DoD  and  industry  standards,  as  shown  in  Table  9.  The  high 
prioritization  of  competency  areas  associated  with  requirements,  architecture  design, 
software  engineering  and  system  assurance  highlights  the  importance  for  sound  up-front 
systems  engineering  process  execution,  IT  systems’  increasing  reliance  on  software  and 
the  paramount  need  for  cybersecurity.  As  far  as  applicable  KSAs  within  each 
competency  area  are  concerned,  Table  10  identifies  KSAs  core  to  the  SSC  Atlantic 
engineering  department  while  Table  1 1  depicts  the  basic  KSAs  common  to  all  systems 
engineers.  By  defining  subroles  (or  specialty  areas)  for  a  systems  engineer,  further  KSAs 
can  be  defined  that  stress  certain  competency  areas  over  others.  Figure  16  depicts 
example  specialty  areas  associated  with  the  systems  engineer  role. 

Research  question  2  asks  how  GRCSE  can  be  used  to  effectively  employ  a  CDM. 
GRCSE  provides  a  process  script  for  competency-based  curriculum  development,  as 
shown  in  Figure  27  from  GRCSE  vl.O.  Chapter  V,  Section  C  of  this  thesis  describes  how 
SE  curriculum  development  should  optimally  be  accomplished  by  taking  both  a  holistic 
(top-down)  approach — tailored  from  GRCSE’s  process  script — as  well  as  a  bottom-up 
approach.  The  GRCSE-based  top-down  approach  can  be  effective  in  training  to  the 
breadth  of  competency  area  and  KSA  coverage  desired  in  a  SE  curriculum.  A  bottom-up 
approach  can  be  effective  in  ensuring  that  the  voice  of  the  employee  (the  systems 
engineer  in  this  case)  is  adequately  heard  as  well  and  ultimately  considered  when 
establishing  the  SE  training  curriculum. 
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Research  question  3  asks  how  various  forms  of  education  and  training  can  best 
support  the  development  of  KSAs  required  to  develop  competent  systems  engineers  at 
SSC  Atlantic.  Chapter  V  explores  various  forms  of  education  and  training  that  can  be 
used  to  develop  systems  engineers,  or  in  other  words,  train  systems  engineers  on  the 
KSAs  needed  in  their  CDM.  Figure  28  provides  a  simple  decision  tree  for  determining 
when  various  forms  of  education  and  training  may  typically  be  most  effective  for 
developing  KSAs  in  different  competency  areas  or  at  different  levels  of  Bloom’s 
taxonomy.  Table  17  provides  recommended  development  (or  education  and  training) 
methods  for  each  KSA  defined  in  an  SSC  Atlantic  systems  engineer’s  CDM. 

B.  CONCLUSION 

In  order  to  properly  develop  a  SE  workforce  in  an  IT  command  such  as  SSC 
Atlantic,  one  must  first  understand  what  competency  areas  and  KSAs  systems  engineers 
must  attain.  A  SE  competency  framework  should  consider  the  SE  life  cycle  processes, 
but  also  technology  areas,  mission/capability  areas  and  leadership  skills  to  ensure  that 
systems  engineers  are  well  rounded  in  order  to  provide  technical  leadership  to  multi¬ 
disciplinary  teams  with  role-diverse  team  members.  When  establishing  a  competency 
framework,  careful  consideration  should  be  made  toward  which  precise  use  case(s)  will 
be  supported  by  the  framework.  Not  understanding  the  context  and  use  of  the 
competency  framework  can  lead  to  a  tremendous  amount  of  KSA  analysis  that  can  be 
rendered  useless  or  impractical.  Identifying  relevant  and  authoritative  competency  area 
and  KSA  sources  for  the  competency  framework  is  also  critical,  as  there  is  no  need  to 
recreate  data  that  has  already  been  adequately  developed  by  several  other  relevant  and 
established  industry  and  DoD  organizations.  In  particular,  the  INCOSE,  DAU  SPRDE- 
SE,  NASA  and  Navy  SE  competency  models  proved  highly  relevant  to  the  execution  of 
SE  at  SSC  Atlantic.  Due  to  SSC  Atlantic’s  mission  focus  on  IT  and  cyberspace,  the 
NIST  national  cybersecurity  workforce  framework  also  proved  highly  useful  in  tailoring 
a  SE  competency  framework. 

When  prioritizing  competency  areas  and  KSAs,  each  SE  use  case  must  be 
considered  separately  as  each  will  likely  emphasize  different  competency  areas. 
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Competency  areas  such  as  stakeholder  requirements  definition,  requirements  analysis, 
architecture  design,  software  engineering,  acquisition,  verification  and  system  assurance 
require  more  emphasis  at  SSC  Atlantic  than  others.  In  order  to  establish  a  complete  set 
of  KSAs  at  each  competency  development  stage,  a  layered-cake  approach  should  be 
taken,  meaning  that  KSAs  will  be  applicable  to  an  increasingly  narrowed  sector  of 
individuals.  For  example,  Figure  30  shows  how  every  SSC  Atlantic  employee  needs 
leadership  skills,  members  of  the  entire  engineering  department  require  “core” 
engineering  skills,  all  systems  engineers  require  a  certain  set  of  KSAs  and  then  specific 
sub-roles  or  types  of  systems  engineers  require  yet  a  separate  set  of  KSAs.  Each  of  these 
KSA  sets  is  ultimately  part  of  a  systems  engineer’s  competency  development  model.  In 
order  to  establish  systems  engineering  roles  that  can  be  well  understood  across  the 
organization,  one  must  examine  the  roles  that  will  interact  with  the  role  of  an  SE  in  order 
to  determine  where  KSAs  will  be  shared  across  the  roles  or  unique  to  one  or  the  other. 
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Figure  30.  SSC  Atlantic  SE  Competency  Framework  KSA  Pyramid 

Simply  understanding  which  KSAs  are  most  critical  to  developing  systems 
engineers  is  insufficient.  Analysis  must  be  conducted  to  understand  how  these  KSAs  can 
and  should  be  obtained.  There  are  a  number  of  ways  to  develop  SE  KSAs.  The  most 
common  methods  are  through  educational  training  (DAU,  degrees  or  certifications),  in¬ 
house-developed  training  courses/workshops,  and  OJT.  DAU  SPRDE-SE  classes  can  be 
effective  when  providing  systems  engineers  with  basic  knowledge  and  comprehension  of 
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the  SE  life  cycle  processes — particularly  in  the  areas  of  acquisition  and  risk  management. 
Leadership  skills  can  be  developed  through  programs  such  as  the  Mid-Career  Leadership 
and  Mentorship  Programs.  OJT  can  be  enhanced  when  coupled  with  targeted  rotational 
opportunities  and  job  shadowing  opportunities.  If  approached  systematically, 
immeasurable  value  can  be  obtained  from  developing  in-house  SE  training  that  engages 
systems  engineers  at  all  levels  of  the  workforce.  GRCSE  provides  useful,  tailorable 
recommendations  on  how  to  develop  and  assess  SE  curricula.  When  it  comes  to 
assessing  the  competency  of  systems  engineers,  care  must  be  taken  to  choose  an 
assessment  process  and  associated  assessment  methodologies  that  are  relatively  thorough 
yet  not  overly  cumbersome,  time-consuming  and  costly. 

C.  FUTURE  RESEARCH 

While  the  topic  of  SE  workforce  development  has  been  heavily  studied  over  the 
last  decade,  there  are  still  a  large  number  of  related  areas  that  need  additional  research 
and  analysis.  Those  interested  in  furthering  the  subject  of  SE  workforce  development 
should  consider  KSA  configuration  management  methods,  competency  framework 
management  tools,  and  long-term  SE  career  progression  models.  As  more  DoD  and 
industry  SE  organizations  embrace  the  use  of  competency  models,  the  need  to  vet 
feedback  and  refine  competency  model  KSAs  will  grow.  As  competency  areas  and 
KSAs  evolve,  recommendations  should  also  be  made  on  how  systems  engineers  are  re¬ 
certified  to  keep  up  with  the  latest  principles  and  trends.  Competency  framework  and 
KSA  management  tools  could  significantly  reduce  the  burden  of  managing  the 
recommended  KSAs  of  the  SE  organizations  as  well  as  the  KSAs  specifically  obtained  by 
individual  systems  engineers;  yet,  they  largely  do  not  exist  today.  Publications  such  as 
GRCSE  vl.O  depict  general  career  progression  models  for  systems  engineers;  however, 
as  SE  competency  frameworks  become  more  stable  and  better  understood  by  the  greater 
SE  workforce  in  the  US,  recommendations  should  be  made  as  to  specific,  notional  ways 
that  systems  engineers  could  and  should  pursue  developing  different  KSAs  and  taking 
advantage  of  different  opportunities  over  the  course  of  their  careers.  Another  area  that 
could  be  further  explored  is  the  applicability  of  project  management  processes  and  IT 

topics  from  PMI  and  SFIA,  respectively,  to  SE  frameworks. 
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APPENDIX  A.  COMPETENCY  MODEL  USE  CASE  PROCESSES 


The  following  competency  model  use  case  process  models/figures  were 
developed  in  collaboration  with  the  SSC  Atlantic  Workforce  Management  Office  in  order 
to  better  understand  the  context  and  uses  of  CDM  and  KSA  data. 


Figure  3 1 .  SSC  Atlantic  Organizational  Capability  Development 
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Figure  32.  SSC  Atlantic  Individual  Competency  Development 


Figure  33.  SSC  Atlantic  IPT  Staffing  Process 
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APPENDIX  B.  LEADERSHIP  SKILLS 


The  following  leadership  skills  and  associated  indicators  were  tailored  from  the 
2011  version  of  Office  of  Personnel  Management  (OPM)  leadership  competency 
framework  for  use  at  SSC  Atlantic. 


Leadership  Skill  / 
Personal  Attribute 

Definition  /  Indicators 

Stage 

Accountability 

Holds  self  and  others  accountable  for  measurable  high- 
quality,  timely,  and  cost-effective  results. 

Intermediate 

Accountability 

Focuses  on  results  and  measuring  attainment  of  outcomes. 

Intermediate 

Accountability 

Determines  objectives,  sets  priorities,  and  delegates  work. 

Intermediate 

Accountability 

Accepts  responsibility  for  mistakes. 

Entry 

Accountability 

Complies  with  established  control  systems  and  rules. 

Entry 

Accountability 

Completes  projects  within  areas  of  specific  responsibility  in 
a  timely  manner  and  within  budget. 

Intermediate 

Communication — 

Oral 

Effectively  and  convincingly  expresses  information  (for 
example,  ideas  or  facts)  to  individuals  or  groups  effectively, 
taking  into  account  the  audience  and  nature  of  the 
information  (for  example,  technical,  sensitive, 
controversial). 

Intermediate 

Communication — 

Oral 

Expresses  oral  information  (i.e.  ideas  or  facts)  clearly, 
effectively,  and  with  appropriate  command  of  the  English 
language. 

Entry 

Communication — 

Oral 

Listens  effectively,  including  recognizing  nonverbal  cues. 
Clarifies  information  as  needed.  Seeks  first  to  understand 
and  then  to  be  understood. 

Intermediate 

Communication — 

Oral 

Uses  verbal  and  non-verbal  communication  to  enhance 
message 

Entry 

Communication — 

Oral 

Facilitates  an  open  exchange  of  ideas  and  fosters  an 
atmosphere  of  open  communication. 

Intermediate 

Communication — 

Oral 

Ensures  timely  communication,  sharing  information  and 
concerns. 

Entry 

Communication — 

Oral 

Listens  to  others,  attends  to  nonverbal  cues,  and  responds 
appropriately. 

Intermediate 

Communication — 

Oral 

Creates  and  utilizes  media  (i.e.  transparencies,  PowerPoint, 
etc.)  for  presentations. 

Entry 

Communication — 

Oral 

Creates  effective,  organized  presentations. 

Intermediate 

Communication — 

Oral 

Makes  clear  and  convincing  oral  presentations; 

Intermediate 

Communication — 

Oral 

Listens  to  others,  attends  to  nonverbal  cues,  and  responds 
appropriately. 

Intermediate 

Communication — 

Oral 

Performs  the  process  of  offering  information  or  data  for 
consideration  or  display. 

Entry 
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Leadership  Skill  / 
Personal  Attribute 

Definition  /  Indicators 

Stage 

Communication  - 
Written 

Recognizes  and  uses  correct  English  grammar,  punctuation, 
and  spelling. 

Entry 

Communication  - 
Written 

Communicates  written  information  (for  example,  facts, 
ideas,  or  messages)  in  a  succinct  and  organized  manner. 

Intermediate 

Communication  - 
Written 

Produces  written  information,  which  may  include  technical 
material  that  is  appropriate  for  the  intended  audience. 

Intermediate 

Conflict  Management 

Identifies  and  takes  steps  to  prevent  potential  situations  that 
could  result  in  unpleasant  confrontations. 

Intermediate 

Conflict  Management 

Manages  and  resolves  conflicts,  grievances,  confrontations, 
or  disagreements  in  a  constructive  manner  to  minimize 
negative  personal  impact. 

Advanced 

Conflict  Management 

Applies  appropriate  rules  and  protocol  for  resolving 
conflicts. 

Advanced 

Conflict  Management 

Formulates  solutions  to  mitigate  and  resolve  conflict. 

Advanced 

Continual  Learning 

Assesses  and  recognizes  own  strengths  and  weaknesses 

Intermediate 

Continual  Learning 

Pursues  self-development 

Entry 

Continual  Learning 

Grasps  the  essence  of  new  information. 

Entry 

Continual  Learning 

Masters  new  technical  and  business  knowledge. 

Entry 

Continual  Learning 

Seeks  feedback  from  others  and  opportunities  to  master  new 
knowledge. 

Entry 

Continual  Learning 

Processes  new  information  for  later  application. 

Intermediate 

Continual  Learning 

Applies  information  learned. 

Entry 

Creativity/ 

Innovation 

Develops  new  insights  into  situations  and  applies  innovative 
solutions  to  make  organizational  improvements. 

Intermediate 

Creativity/ 

Innovation 

Creates  a  work  environment  that  encourages  creative 
thinking,  new  ideas,  and  innovation. 

Intermediate 

Creativity/ 

Innovation 

Designs  and  implements  new  or  cutting  edge 
programs/processes. 

Advanced 

Creativity/ 

Innovation 

Questions  conventional  approaches 

Intermediate 

Creativity/ 

Innovation 

Develops  new  innovations,  solutions,  and  insights. 

Entry 

Creativity/ 

Innovation 

Evaluates  conventional  approaches. 

Intermediate 

Customer  Service 

Understands  available  products  and  services. 

Intermediate 

Customer  Service 

Readily  readjusts  priorities  to  respond  to  pressing  and 
changing  client  demands. 

Intermediate 
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Leadership  Skill  / 
Personal  Attribute 

Definition  /  Indicators 

Stage 

Customer  Service 

Works  with  clients  and  customers  (that  is,  any  individuals 
who  use  or  receive  the  services  or  products  that  your  work 
unit  produces,  including  the  general  public,  individuals  who 
work  in  the  agency,  other  agencies,  or  organizations  outside 
the  Government)  to  assess  needs,  provide  information  or 
assistance,  resolve  their  problems,  or  satisfy  their 
expectations; 

Intermediate 

Customer  Service 

Achieves  quality  end-products. 

Intermediate 

Customer  Service 

Is  committed  to  providing  quality  products  and  services. 

Intermediate 

Decisiveness/  Problem 
Solving 

Identifies  and  analyzes  issues  problems. 

Entry 

Decisiveness/  Problem 
Solving 

Makes  sound,  well-informed,  objective  decisions. 

Entry 

Decisiveness/  Problem 
Solving 

Understands  the  potential  consequences  and  outcomes  of 
different  decisions. 

Intermediate 

Decisiveness/  Problem 
Solving 

Makes  effective  and  timely  decisions,  even  when  data  is 
limited  or  solutions  produce  unpleasant  consequences. 

Advanced 

Decisiveness/  Problem 
Solving 

Is  proactive  and  achievement  oriented. 

Intermediate 

Decisiveness/  Problem 
Solving 

Commits  to  action,  even  in  uncertain  situations,  to 
accomplish  organizational  goals;  causes  change. 

Advanced 

Decisiveness/  Problem 
Solving 

Determines  accuracy  and  relevance  of  information 

Intermediate 

Decisiveness/  Problem 
Solving 

Generates  and  evaluates  alternatives  to  make 
recommendations. 

Intermediate 

Decisiveness/  Problem 
Solving 

Conducts  scholarly  or  scientific  investigation  or  inquiry  to 
solve  a  problem  or  inquiry  to  enhance  understanding. 

Intermediate 

Decisiveness/  Problem 
Solving 

Uses  results  to  make  appropriate  recommendations  or 
decisions. 

Intermediate 

Decisiveness/  Problem 
Solving 

Creates  alternative  solutions  to  address  a  problem. 

Intermediate 

Entrepreneurship 

Recognizes  new  opportunities. 

Entry 

Entrepreneurship 

Positions  the  organization  for  future  success  by  identifying 
new  opportunities. 

Intermediate 

Entrepreneurship 

Builds  the  organization  by  developing  or  improving 
products  or  services. 

Advanced 

Entrepreneurship 

Takes  calculated  risks  to  accomplish  organizational 
objectives. 

Advanced 

External  Awareness/ 
Political  Savvy 

Identifies,  understands,  and  keeps  up  to  date  on  key  national 
and  international  policies  and  economic,  political,  and  social 
trends  that  affect  the  organization. 

Advanced 

External  Awareness/ 
Political  Savvy 

Evaluates  the  impact  of  pertinent  issues. 

Advanced 
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Leadership  Skill  / 
Personal  Attribute 

Definition  /  Indicators 

Stage 

External  Awareness/ 
Political  Savvy 

Understands  near-term  and  long-range  plans  and  determines 
how  best  to  be  positioned  to  achieve  a  competitive  business 
advantage  in  a  global  economy. 

Expert 

External  Awareness/ 
Political  Savvy 

Develops  plans  to  achieve  a  competitive  business  advantage 
in  a  global  economy. 

Expert 

External  Awareness/ 
Political  Savvy 

Identifies  the  internal  and  external  politics  that  impact  the 
work  of  the  organization. 

Advanced 

External  Awareness/ 
Political  Savvy 

Approaches  each  problem  or  situation  with  a  clear 
perception  of  organizational  and  political  reality. 

Advanced 

External  Awareness/ 
Political  Savvy 

Recognizes  the  impact  of  alternative  courses  of  action. 

Advanced 

Financial 

Management 

Applies  understanding  of  organization’s  financial  processes 
necessary  to  ensure  appropriate  funding  levels. 

Intermediate 

Financial 

Management 

Prepares,  justifies,  and/or  administers  the  budget  for  the 
program  area. 

Intermediate 

Financial 

Management 

Uses  cost-benefit  approaches  to  set  priorities. 

Intermediate 

Financial 

Management 

Monitors  expenditures  and  uses  cost-benefit  thinking  to  set 
priorities. 

Intermediate 

Financial 

Management 

Identifies  cost-effective  approaches. 

Intermediate 

Financial 

Management 

Applies  procurement  and  contracting  processes  to  programs 
and  projects. 

Intermediate 

Financial 

Management 

Evaluates  procurement  and  contracting  processes. 

Advanced 

Financial 

Management 

Oversees  procurement  and  contracting  to  achieve  desired 
results. 

Advanced 

Flexibility/Resilience 

Is  open  to  change  and  new  information 

Entry 

Flexibility/Resilience 

Recognizes  change  in  organizational  conditions. 

Intermediate 

Flexibility/Resilience 

Adapts  behavior  and  work  methods  in  response  to  new 
information,  changing  conditions,  or  unexpected  obstacles. 

Entry 

Flexibility/Resilience 

Effectively  deals  with  ambiguity. 

Intermediate 

Flexibility/Resilience 

Deals  effectively  with  pressure. 

Intermediate 

Flexibility/Resilience 

Maintains  focus  and  intensity  in  ambiguous  situations. 

Advanced 

Flexibility/Resilience 

Maintains  focus  and  intensity  in  pressure  situations. 

Intermediate 

Flexibility/Resilience 

Remains  optimistic  and  persistent,  even  under  adversity. 

Intermediate 

Flexibility/Resilience 

Recovers  quickly  from  setbacks. 

Intermediate 

Flexibility/Resilience 

Effectively  balances  personal  life  and  work. 

Intermediate 

Human  Capital 
Management 

Builds  and  manages  workforce  based  on  organizational 
goals,  budget  considerations,  and  staffing  needs. 

Advanced 
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Leadership  Skill  / 
Personal  Attribute 

Definition  /  Indicators 

Stage 

Human  Capital 
Management 

Ensures  that  employees  are  appropriately  recruited,  selected, 
appraised,  and  rewarded 

Advanced 

Human  Capital 
Management 

Recognizes  performance  problems. 

Advanced 

Human  Capital 
Management 

Takes  action  to  address  performance  problems. 

Advanced 

Human  Capital 
Management 

Manages  a  multi-sector  workforce  and  a  variety  of  work 
situations. 

Advanced 

Information 

Management 

Identifies  a  need  for  and  knows  where  or  how  to  gather 
information. 

Intermediate 

Information 

Management 

Organizes  and  maintains  information  or  information 
management  systems. 

Intermediate 

Integrity/Honesty 

Creates  a  culture  that  fosters  high  standards  of  ethics. 

Advanced 

Integrity/Honesty 

Behaves  in  a  fair  and  ethical  manner  toward  others. 

Entry 

Integrity/Honesty 

Demonstrates  a  sense  of  corporate  responsibility. 

Entry 

Integrity/Honesty 

Contributes  to  maintaining  the  integrity  of  the  organization 

Entry 

Integrity/Honesty 

Displays  high  standards  of  ethical  conduct  and  understands 
the  impact  of  violating  these  standards  on  an  organization, 
self,  and  others. 

Intermediate 

Integrity/Honesty 

Is  trusted  by  others  with  tasks  or  information. 

Intermediate 

Interpersonal  Skills 

Shows  understanding,  friendliness,  courtesy,  tact,  empathy, 
concern,  and  politeness  to  others. 

Entry 

Interpersonal  Skills 

Develops  and  maintains  effective  relationships  with  others. 

Intermediate 

Interpersonal  Skills 

Effectively  deals  with  individuals  who  are  difficult,  hostile, 
or  distressed 

Advanced 

Interpersonal  Skills 

Relates  well  to  people  from  varied  backgrounds  and 
different  situations. 

Intermediate 

Interpersonal  Skills 

Considers  cultural  diversity,  race,  gender,  disabilities,  and 
other  individual  differences  to  determine  appropriate 
courses  off  action  or  responses. 

Advanced 

Leadership  / 

Influence  / 

Negotiation 

Influences,  motivates,  and  challenges  others  toward  a 
common  goal 

Intermediate 

Leadership  / 

Influence  / 

Negotiation 

Adapts  leadership  styles  to  a  variety  of  situations. 

Advanced 

Leadership  / 

Influence  / 

Negotiation 

Persuades  others  to  accept  recommendations  or  cooperate. 

Advanced 

Leadership  / 

Influence  / 

Negotiation 

Builds  consensus  through  give  and  take. 

Advanced 
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Leadership  Skill  / 
Personal  Attribute 

Definition  /  Indicators 

Stage 

Leadership  / 

Influence  / 

Negotiation 

Gains  cooperation  from  others  to  obtain  information  and 
accomplish  goals. 

Intermediate 

Leadership  / 

Influence  / 

Negotiation 

Works  with  others  to  reach  an  agreement 

Intermediate 

Leadership  / 

Influence  / 

Negotiation 

Negotiates  to  find  mutually  acceptable  solutions. 

Intermediate 

Partnering/ 

Collaborative 

Performance 

Develops  networks  and  builds  alliances. 

Advanced 

Partnering/ 

Collaborative 

Performance 

Engages  in  cross-functional  activities. 

Intermediate 

Partnering/ 

Collaborative 

Performance 

Collaborates  across  boundaries,  and  finds  or  achieves 
common  ground  with  a  widening  range  of  stakeholders. 

Advanced 

Partnering/ 

Collaborative 

Performance 

Utilizes  contacts  to  build  and  strengthen  internal  support 
bases. 

Intermediate 

Partnering/ 

Collaborative 

Performance 

Recognizes  commonalities  between  individuals,  groups,  or 
stakeholder  goals. 

Intermediate 

Self-Management 

Systematically  monitors  one’s  own  efforts  and  making 
appropriate  modifications  to  ensure  alignment  with  current 
or  changing  needs  or  goals. 

Intermediate 

Self-Management 

Recognizes  changes  that  warrant  behavioral  adaptations. 

Intermediate 

Self-Management 

Sets  well-defined  and  realistic  personal  goals. 

Entry 

Self-Management 

Displays  a  high  level  of  initiative,  effort,  and  commitment 
towards  completing  assignments  in  a  timely  manner. 

Entry 

Self-Management 

Works  with  minimal  supervision. 

Intermediate 

Self-Management 

Controls  own  goal-directed  behavior  without  immediate 
external  control. 

Intermediate 

Service  Motivation 

Creates  and  sustains  an  organizational  culture  which 
encourages  others  to  provide  the  quality  of  service  essential 
to  high  performance. 

Advanced 

Service  Motivation 

Enables  others  to  acquire  the  tools  and  support  they  need  to 
perform  at  a  competent  level. 

Advanced 

Service  Motivation 

Shows  a  commitment  to  public  service. 

Entry 

Service  Motivation 

Aligns  organizational  objectives  and  practices  with  public 
interests. 

Expert 

Service  Motivation 

Ensures  that  actions  meet  public  needs. 

Advanced 
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Leadership  Skill  / 
Personal  Attribute 

Definition  /  Indicators 

Stage 

Service  Motivation 

Influences  others  toward  a  spirit  of  service  and  meaningful 
contributions  to  mission  accomplishment. 

Advanced 

Strategic 

Thinking/Vision 

Formulates  effective  strategies  consistent  with  the  business 
and  competitive  strategy  of  the  organization  in  a  global 
economy. 

Expert 

Strategic 

Thinking/Vision 

Examines  policy  issues  and  strategic  planning  with  a  long¬ 
term  perspective. 

Expert 

Strategic 

Thinking/Vision 

Determines  objectives  and  sets  priorities. 

Entry 

Strategic 

Thinking/Vision 

Anticipates  potential  threats  or  opportunities. 

Intermediate 

Strategic 

Thinking/Vision 

Envisions  positive  organizational  possibilities. 

Advanced 

Strategic 

Thinking/Vision 

Develops  the  necessary  procedures  and  operations  to 
achieve  organizational  possibilities. 

Advanced 

Strategic 

Thinking/Vision 

Develops  appropriate  measures  to  evaluate  achievement. 

Advanced 

Strategic 

Thinking/Vision 

Understands  where  the  organization  is  headed  and  how  to 
make  a  contribution 

Intermediate 

Strategic 

Thinking/Vision 

Takes  a  long-term  view  and  recognizes  opportunities  to  help 
the  organization  accomplish  its  objectives  or  move  toward 
the  vision. 

Advanced 

Strategic 

Thinking/Vision 

Builds  a  shared  vision  with  others. 

Advanced 

Strategic 

Thinking/Vision 

Influences  others  to  translate  vision  into  action. 

Advanced 

Team  Building 

Inspires  and  fosters  team  commitment,  spirit,  pride,  and 
trust. 

Intermediate 

Team  Building 

Facilitates  cooperation  and  motivates  team  members  to 
accomplish  group  goals. 

Intermediate 

Team  Building 

Consistently  develops  and  sustains  cooperative  working 
relationships. 

Intermediate 

Team  Building 

Encourages  and  facilitates  cooperation  and  motivation 
within  the  organization  and  with  customer  groups  to 
accomplish  a  common  goal. 

Advanced 

Team  Building 

Fosters  commitment,  team  spirit,  pride,  trust. 

Advanced 

Team  Building 

Develops  capabilities  in  others  through  coaching, 
mentoring,  rewarding,  and  guiding  employees. 

Advanced 

Technical  Expertise 

Uses  knowledge  that  is  acquired  through  formal  training  or 
extensive  on-the-job  experience  to  perform  one's  job 

Entry 

Technical  Expertise 

Evaluates  the  technical  sufficiency  of  work 

Advanced 

Technical  Expertise 

Works  with,  understands,  and  evaluates  technical 
information  related  to  the  job 

Intermediate 
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Leadership  Skill  / 
Personal  Attribute 

Definition  /  Indicators 

Stage 

Technical  Expertise 

Advises  others  on  technical  issues. 

Expert 

Technology 

Credibility 

Applies  principles,  procedures,  requirements,  regulations, 
and  policies  related  to  specialized  expertise. 

Expert 

Technology 

Credibility 

Understands  linkages  between  administrative  competencies 
and  mission  needs. 

Advanced 

Technology 

Credibility 

Addresses  training  and  development  needs. 

Advanced 

Technology 

Management 

Maintains  knowledge  concerning  technological 
developments. 

Expert 

Technology 

Management 

Recognizes  opportunities  to  integrate  technology  into  the 
workplace. 

Intermediate 

Technology 

Management 

Integrates  technology  into  the  workplace  to  achieve  results 
and  improve  program  effectiveness. 

Advanced 

Technology 

Management 

Evaluates  and  plans  for  the  impact  of  technological  changes 
on  the  organization. 

Advanced 

Technology 

Management 

Creates  and  maintains  an  accessible,  secure  technology 
system. 

Advanced 

Table  12.  Recommended  Leadership  Skills  for  Systems  Engineers  (After  Office  of 

Personnel  Management,  2011) 
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APPENDIX  C.  SSC  ATLANTIC  ENGINEERING  DEPARTMENT 

ROLE  DESCRIPTIONS 


As  of  July  2013,  the  following  eight  primary  roles  have  been  defined  within  the 
SSC  Atlantic  Engineering  Department  (in  addition  to  that  of  a  systems  engineer).  An 
individual  on  an  IPT  may  perform  in  one  or  more  roles  at  any  given  time.  These  roles  are 
subject  to  collapse  into  one  another,  expand  or  change  in  any  way  over  time. 

•  Technical  Specialist — Configure,  implement,  deliver,  administer, 

troubleshoot  and  support  information  technology  (IT)  systems  and 
services.  Paramount  requirement  is  knowledge  of  IT  principles,  concepts, 
and  methods;  Within  their  areas  of  expertise,  technical  specialists  advise 
and  contribute  to  the  design,  development  and  implementation  of  solutions 
while  ensuring  compliance  with  relevant  domain  policies,  processes  and 
standards.  Early  in  the  solution  lifecycle,  they  ensure  mission  relevancy, 
support  needs  and  feasibility  analysis,  decompose  specifications, 
recommend  alternatives  and  inform  critical  design  decisions.  Later  in  the 
lifecycle,  technical  specialists  contribute  domain  expertise  within  tests, 
support  installations,  evaluate  the  solution  against  design  or  performance 
requirements  and  recommend  necessary  improvements  or  corrections. 

•  Enterprise  Architect — Establishes  and  communicates  mission  and 
organizational  needs;  Develops  and  analyzes  Concept  of  Operations; 
Defines  capabilities,  objectives,  and  measures  of  effectiveness 
(MOE)/measures  of  performance  (MOP);  Develops  and  evolves 
enterprise,  System  of  Systems  (SoS),  and  solution  architectures;  Conducts 
capability  assessments  and  analysis;  Develops,  analyzes,  and  manages 
requirements;  Identifies,  defines  and  manages  system  interfaces;  Assesses 
impacts  of  SoS  and  solution  performance  and  upgrades;  Conducts  reviews 
and  assessment  focused  on  interoperability  and  management  of  risk; 
Manages  strategic  evolution  of  systems. 

•  Software  Professional — Applies  a  systematic,  disciplined,  quantifiable 
approach  to  the  design,  development,  coding,  operation,  and  maintenance 
of  software,  and  the  study  of  these  approaches. 

•  Data  Professional — Responsible  for  the  installation,  configuration,  and 
administration  of  database  management  systems  or  the  management  of 
data  including  architecture,  analysis,  and  modeling. 

•  Information  Technology  Service  Management  Specialist — Leads  an 
integrated  discipline  for  developing,  improving  and  assuring  the  quality  of 
IT  services  and  their  management  systems.  Focuses  on  optimizing 
processes,  personnel,  technologies  and  organizational  structures 
contributing  to  standardization  and  enforcement  of  enterprise  behavior 
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around  the  customer's  desired  capabilities  and  bound  by  defined 
performance  measures  conformant  with  relevant  standards  and 
frameworks  to  reduce  Total  Cost  of  Ownership  (TCO)  and  assure  mission 
accomplishment 

•  Tester — Understands  the  intended  purpose,  operational  context  and 
concept  of  use  of  proposed  systems.  Plans  and  executes  procedures  to 
obtain,  verify  or  provide  data  for  the  evaluation  of  progress  in 
accomplishing  developmental  objectives,  the  performance,  operational 
capability  and  suitability  of  systems,  subsystems,  component  and 
equipment  items,  and  their  vulnerability  and  lethality.  Verifies  status  of 
technical  progress,  verifies  that  design  risks  are  minimized,  substantiates 
achievement  of  contract  technical  performance,  certifies  readiness  for 
initial  operational  testing  (OT).  Advises  on  testability  of  requirements  and 
on  risk  involved  in  testing  those  requirements. 

•  Information  Assurance  Professional — Conduct  scientific  and 

engineering  activities  that  protect  and  defend  information  and  information 
systems  by  ensuring  their  availability,  integrity  and  confidentiality.  These 
activities  require  expertise  for  the  development  and  deployment  of 
technical  measures  to  protect  and  defend  networks,  cyber  systems, 
computers,  and  information  from  disruption,  denial,  degradation,  or 
destruction  and  for  the  restoration  of  information  and  information  systems. 
Provide  IA  engineering  expertise  to  support  Information  Operations 
capabilities 

•  Mission  Specialist — Uses  a  deep  understanding  of  the  context, 
characteristics  and  concepts  of  the  customer's  mission  to  define,  guide 
and/or  evaluate  technical  solutions  that  meet  the  operational  needs  of  the 
user 
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APPENDIX  D.  SYSTEMS  ENGINEER  SUBROLE/SPECIALTY 

ROLE  CARD  SAMPLES 


A.  ROLE  CARD  SAMPLE:  SYSTEMS  ENGINEER— TECHNICAL 
MANAGEMENT 


Specialty:  Technical  Management 

Identifies  scope  of  engineering/technical  tasks  on  an  IPT.  Determines  the  technical  expertise  and  engineering 
processes  required  to  support  the  IPT  based  on  customer  needs.  Determine  the  roles/KSAs  needed  on  an  IPT  and 
when  to  submit  demand  signals  out  to  the  appropriate  competencies.  Leads  Technical  Reviews  (SETRs,  etc.). 
Ensures  proper  review  of  engineering/technical  deliverables  produced  by  the  project  or  IPT.  Serves  as  the 
Engineering  advisors  for  the  IPT  and  adheres  to  latest  Command  Engineering  initiatives. 

Note:  The  role  of  Systems  Engineer — Technical  Management  may  also  be  known  as  Lead  Systems  Engineer, 
Lead  Systems  Integrator,  Technical  Manager  or  Technical  Lead _ 

Typical  Series:  Typical  DAWIA  Career  Path: 

0800  Series  Engineers,  1515  Operations  SPRDE-SE 

Research  Analysts,  1550  Computer  Scientists _ 

Recommended  Training:  SE  Planning,  Intro  to  Requirements,  Intro  to  Architecture,  Systems  Thinking,  Intro 
to  Complex  Systems _ 

Typical  Work  Products:  Systems  Engineering  Plan,  Requirements  Doc/Matrix,  Design  Plans,  Interface 
Design/Ctrl  Document,  Work  Breakdown  Structure  &  Schedule  Inputs _ 

Table  13.  Systems  Engineer — Technical  Management  Role  Card  Information 


CDM  Stage 

Competency  Area 

Knowledge,  Skill  or  Ability  (KSA) 

Entry 

Stakeholder 

Requirements 

Definition 

Assists  in  defining  the  business  and  mission  need  for  systems  that  will  provide  services, 
capabilities  or  platforms  to  end  users  and  other  stakeholders. 

Entry 

Requirements 

Analysis 

Analyzes,  manages,  and  traces  systems  requirements. 

Entry 

Architecture  Design 

Identifies  systems  interfaces  and  interoperability  concerns. 

Intermediate 

Systems  Thinking 

Demonstrates  a  broad  understanding  of  the  system  context  and  environment 

Intermediate 

Architecture  Design 

Ability  to  develop  a  preliminary  subsystem  design  based  on  existing  best  practices 

Intermediate 

Architecture  Design 

Ability  to  perform  an  Analysis  of  Alternatives  (AoA) 

Intermediate 

Technical  Planning 

Understands  the  role  of  systems  engineering  planning  as  part  of  an  overall 
project/program  plan 

Intermediate 

Technical  Planning 

Knowledge  of  the  command's  global  WBS 

Intermediate 

Technical 

Assessment 

Develops  design  review  and  milestone  decision  approaches 

Advanced 

Technical  Planning 

Ability  to  develop  a  detailed  Systems  Engineering  Plan 

Expert 

Technical 

Assessment 

Able  to  chair  variety  of  technical  review  boards  (e.g.  PDR,  CDR,  TRR) 

Expert 

Integration 

Ability  to  identify  and  address  issues  associated  with  connecting  multiple  systems 
across  organizational  boundaries. 

Table  14.  Systems  Engineer — Technical  Management  Key  KSAs 
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B. 


ROLE  CARD  SAMPLE:  SYSTEMS  ENGINEER— PLATFORMS 


Specialty:  Platforms 

Provides  engineering  discipline  in  support  of  installing  systems  into  a  physical  platform  to  ensure  that 
environmental,  mounting,  heat,  power,  lighting,  network  infrastructure,  safety,  ergonomics  and/or  survivability 
requirements  are  met.  Also  ensures  integration  between  system  components.  Primary  process  areas  of  interest 
include  site  surveys,  Installation  Design  Plan  and/or  Technical  Data  Package  development  and  review,  BESEP 
creation,  installation/integration  oversight  and  PITCOs/SOVTs. 

Note:  Platform  Systems  Engineer  may  also  be  known  as  Platform  Engineer  or  Project  Engineer _ 

Typical  Series:  Typical  DAWIA  Career  Path: 

0800  Series  Engineers _ SPRDE-SE _ 

Recommended  Training:  Site  Surveys,  SE  Planning,  Shore  Installation  Process  Handbook, 
Intro  to  Technical  Data  Packages  or  Installation  Design  Plans,  Analysis  of  Alternatives _ 

Typical  Work  Products:  Systems  Engineering  Plans,  Base  Electronic  Systems  Engineering 
Plans,  Assessment  Reports,  Site  Survey  Reports,  Requirements  Doc/Matrix  Design  Plans, 
System  Operation  Verification  &  Test  Docs _ 

Sub-specialties:  Ashore  (Command  Centers,  Air  Traffic  Control  Facilities,  Fuel  Handling 
Facilities,  Electronic  Security  Systems,  etc.),  Vehicular,  Afloat,  Expeditionary,  Subsurface,  etc. 

Table  15.  Systems  Engineer — Platforms  Role  Card  Information 


CDM  Stage 

Competency  Area 

Knowledge,  Skill  or  Ability  (KSA) 

Entry 

Requirements 

Analysis 

Analyzes,  manages,  and  traces  systems  requirements. 

Entry 

Platforms 

Ability  to  use  a  checklist  to  review  an  Installation  Design  Plan  (IDP) 

Entry 

Platforms 

Basic  knowledge  of  computer,  network  and  communications  cabling  and  connectors 

Intermediate 

Stakeholder 

Requirements 

Definition 

Assesses  key  conditions,  constraints,  conflicting  requirements,  and  organizational 
issues,  including  safety  and  security  factors. 

Intermediate 

Platforms 

Knowledge/skill  in  shore  installation/upgrade  processes  (e.g.,  the  Shore  Installation 
Process  Handbook),  including  design,  development,  acquisition,  documentation,  CM, 
scheduling,  resource  management,  site  surveys,  installations,  system  cutover.  System 
Operational  Verification  and  Testing  (SOVT)  &  system  turnover 

Intermediate 

Architecture  Design 

Ability  to  perform  an  Analysis  of  Alternatives  (AoA) 

Advanced 

Architecture  Design 

Specify  power  supply  and  heating,  ventilation,  and  air  conditioning  (HVAC) 
requirements  and  configuration  based  on  system  performance  expectations  and  design 
specifications 

Advanced 

System  Assurance 

Design  and  develop  secure  interfaces  specifications  between  interconnected  systems 

Advanced 

Requirements 

Analysis 

Recommends  changes  to  systems  requirements  to  align  with  government  policy,  and 
addresses  future  integration  and  interoperability  challenges  across  programs  or  the 
enterprise. 

Expert 

Integration 

Ability  to  define  SSC  Atlantic  product  &  platform  integration  policies 

Table  16.  Systems  Engineer — Platforms  Key  KSAs 
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APPENDIX  E.  RECOMMENDED  WORKFORCE  DEVELOPMENT  METHODS  FOR  EACH 

SYSTEMS  ENGINEER  KSA 


The  following  table  displays  each  systems  engineer  KSA  by  competency  vector,  competency  area  and  stage.  The 


recommended  development  method  for  each  KSA  and  the  associated  justification  are  shown  in  the  far  right  columns  of  the  table. 


Compete 

ncy 

Vector 

Competency  Area 

KSA 

Stage 

Recom¬ 

mended 

Method 

Justification  /  Comments 

Activity 

GENERAL 

Basic  knowledge  of  technical  and  technical 
mgt  processes 

Entry 

DAU 

well  covered  in  DAU 

SPRDE-SE  curriculum 

Activity 

GENERAL 

Knowledge  of  engineering/technical  artifacts 
required  by  SSC  Atlantic 

Entry 

in- 

house 

unique  to  SSC  Atlantic 

Activity 

GENERAL 

Ability  to  review  engineering/technical 
artifacts  for  completeness  and  quality 

Intermediate 

in- 

house 

unique  to  SSC  Atlantic 

Activity 

1.0  TECHNICAL  BASIS 

FOR  COST 

Knowledge  of  SPAWAR  accounting  and 
financial  systems 

Entry 

in- 

house 

unique  to  SSC  Atlantic 

Activity 

1.0  TECHNICAL  BASIS 

FOR  COST 

Ability  to  contribute  to  timely  and  accurate  full 
cost  budget  information  (such  as  labor, 
procurement,  travel  estimates)  to  project 
managers  when  requested 

Entry 

in- 

house 

unique  to  SSC  Atlantic  cost 
estimation  methods/tools 

Activity 

1.0  TECHNICAL  BASIS 

FOR  COST 

Ability  to  perform  cost  estimating  on  technical 
work  products 

Entry 

OJT 

experiential  developmental 
activities  required 

Activity 

1.0  TECHNICAL  BASIS 

FOR  COST 

Ability  to  use  Work  Breakdown  Structure 
(WBS)  as  a  tool  for  tracking  actual  vs. 
estimated  costs  and  use  this  information  to 
revise  cost  models  appropriately 

Entry 

DAU 

well  covered  in  DAU 

SPRDE-SE  curriculum 

99 


Compete 

ncy 

Vector 

Competency  Area 

KSA 

Stage 

Recom¬ 

mended 

Method 

Justification  /  Comments 

Activity 

2.0  MODELING  & 

SIMULATION 

Knowledge  of  decision  support  tools,  models, 
or  simulations  that  are  applicable  to  your  job. 

Entry 

in- 

house 

unique  to  SSC  Atlantic 
models,  use  cases 

Activity 

3.0  SAFETY 

ASSURANCE 

Understand  and  comply  with  safety  strategies, 
policies,  and  standards 

Entry 

external 

vendor 

Not  covered  by  DAU 

Activity 

3.0  SAFETY 

ASSURANCE 

Understands  the  relationship  between 
reliability,  availability,  maintainability  and 
safety 

Intermediate 

degree/ 

cert 

academia  provides  ample 
RAM  material 

Activity 

4.0  STAKEHOLDER 

REQUIREMENTS 

DEFINITION 

Able  to  identify  major  stakeholders 

Entry 

in- 

house 

stakeholder  groups 
somewhat  specific  to  SSC 
Atlantic 

Activity 

4.0  STAKEHOLDER 

REQUIREMENTS 

DEFINITION 

Understand  the  importance  of  requirements 
traceability 

Entry 

DAU 

well  covered  in  DAU 

SPRDE-SE  curriculum 

Activity 

4.0  STAKEHOLDER 

REQUIREMENTS 

DEFINITION 

Can  support  the  elicitation  of  requirements 
from  stakeholders 

Intermediate 

OJT 

experiential  developmental 
activities  required 

Activity 

5.0  REQUIREMENTS 
ANALYSIS 

Understands  that  there  are  different  types  of 
requirements  e.g.  functional,  non-functional, 
business  etc. 

Entry 

DAU 

well  covered  in  DAU 

SPRDE-SE  curriculum 

Activity 

5.0  REQUIREMENTS 

ANALYSIS 

Understands  the  importance  of  managing 
requirements  throughout  the  lifecycle 

Entry 

DAU 

well  covered  in  DAU 

SPRDE-SE  curriculum 
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Compete 

ncy 

Vector 

Competency  Area 

KSA 

Stage 

Recom¬ 

mended 

Method 

Justification  /  Comments 

Activity 

5.0  REQUIREMENTS 
ANALYSIS 

Understands  the  need  for  quality 
requirements  (achievable,  verifiable, 
unambiguous,  necessary  and  sufficient, 
complete,  expressed  as  a  need,  consistent, 
and  appropriate) 

Entry 

DAU 

well  covered  in  DAU 

SPRDE-SE  curriculum 

Activity 

5.0  REQUIREMENTS 
ANALYSIS 

Contribute  to  decomposition  of  requirements 

Entry 

in- 

house 

requires  tailored  exercises; 
could  also  be  done  through 
OJT  or  degree/cert 

Activity 

5.0  REQUIREMENTS 
ANALYSIS 

Contribute  to  development  of  specification 
documents 

Entry 

OJT 

difficult  to  train 

Activity 

5.0  REQUIREMENTS 
ANALYSIS 

Understands  the  relationship  between  design 
and  requirements 

Intermediate 

DAU 

could  also  leverage  SE 
degree/cert 

Activity 

5.0  REQUIREMENTS 
ANALYSIS 

Ability  to  identify  and  analyze  requirements 

Intermediate 

in- 

house 

requires  tailored  exercises; 
could  also  be  done  through 
OJT  or  degree/cert 

Activity 

6.0  ARCHITECTURE  DE 

SIGN 

Basic  knowledge  of  the  different  types  of 
architecture 

Entry 

in- 

house 

unique  to  SSC  Atlantic 
application  of  enterprise 
architecture  discipline 

Activity 

6.0  ARCHITECTURE  DE 

SIGN 

Identifies  systems  interfaces  and 
interoperability  concerns. 

Entry 

in- 

house 

basic  ability  could  be 
covered  by  in-house 
training;  otherwise  -  OJT 

Activity 

6.0  ARCHITECTURE  DE 

SIGN 

Understands  the  need  to  explore  alternative 
and  innovative  ways  of  satisfying  the  system 
need 

Entry 

in- 

house 

could  also  leverage  SE 
degree/cert 
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Compete 

ncy 

Vector 

Competency  Area 

KSA 

Stage 

Recom¬ 

mended 

Method 

Justification  /  Comments 

Activity 

6.0  ARCHITECTURE  DE 

SIGN 

Knowledge  of  the  principles  of  architectural 
design  and  its  role  within  the  lifecycle 

Entry 

DAU 

well  covered  in  DAU 

SPRDE-SE  curriculum 

Activity 

6.0  ARCHITECTURE  DE 

SIGN 

Identify  the  basic  elements/sections  of  an 
Technical  Data  Package  (TDP) 

Entry 

in- 

house 

unique  to  SSC  Atlantic 
approach  to  TDPs 

Activity 

10.0  VALIDATION 

Understands  the  purpose  of  validation 

Entry 

DAU 

well  covered  in  DAU 

SPRDE-SE  curriculum 

Activity 

10.0  VALIDATION 

Understand  structure  and  basic  elements  of  a 
SOVT  document 

Entry 

in- 

house 

SOVT  is  a  tailored 
verification  &  validation 
concept 

Activity 

11.0  TRANSITION 

Aware  of  the  type  of  activities  required  for 
transition  to  operation 

Entry 

DAU 

well  covered  in  DAU 

SPRDE-SE  curriculum 

Activity 

12.0  SYSTEM  ASSURA 

NCE 

Knowledge  of  Risk  Management  Framework 
(RMF) 

Entry 

TBD 

RMF  is  in  process  of  being 
released 

Activity 

12.0  SYSTEM  ASSURA 

NCE 

Knowledge  of  information  assurance  principles 
and  tenets  (confidentiality,  integrity, 
availability,  authentication,  non-repudiation). 

Entry 

DAU 

could  also  leverage  SE 
degree/cert 

Activity 

15.0  TECHNICAL  PLAN 

NING 

Basic  knowledge  of  technical 
disciplines/specialties  applicable  to  SSC 

Atlantic 

Entry 

in- 

house 

unique  to  SSC  Atlantic 

Activity 

15.0  TECHNICAL  PLAN 

NING 

Knowledge  of  the  command's  global  WBS 

Intermediate 

in- 

house 

unique  to  SSC  Atlantic 

Activity 

15.0  TECHNICAL  PLAN 

NING 

Able  to  tailor  systems  engineering  processes 
to  meet  the  needs  of  a  specific 
project/program 

Intermediate 

OJT 

experiential  developmental 
activities  required 
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Compete 

ncy 

Vector 

Competency  Area 

KSA 

Stage 

Recom¬ 

mended 

Method 

Justification  /  Comments 

Activity 

15.0  TECHNICAL  PLAN 

NING 

Understands  the  importance  of  planning, 
monitoring  and  controlling  systems 
engineering  activities 

Entry 

DAU 

well  covered  in  DAU 

SPRDE-SE  curriculum 

Activity 

15.0  TECHNICAL  PLAN 

NING 

Aware  that  common  technical  processes  need 
to  be  planned 

Entry 

DAU 

well  covered  in  DAU 

SPRDE-SE  curriculum 

Activity 

16.0  TECHNICAL  ASSES 

SMENT 

Able  to  (for  a  subsystem  or  simple  project) 
monitor  progress  against  plans 

Intermediate 

OJT 

experiential  developmental 
activities  required 

Activity 

16.0  TECHNICAL  ASSES 

SMENT 

Identifies  continuous  process  improvements 
that  enhance  processes,  products,  and  service 
quality. 

Entry 

in- 

house 

In-house  CPI  training 
capability  exists 

Activity 

16.0  TECHNICAL  ASSES 

SMENT 

Aware  of  review  types  and  their  purposes 

Entry 

DAU 

well  covered  in  DAU 
SPRDE-SE  curriculum; 
however,  there  are  SSC 
Atlantic  unique  review 
types  as  well 

Activity 

16.0  TECHNICAL  ASSES 

SMENT 

Aware  of  activities  to  prepare  for  technical 
assessments 

Entry 

DAU 

well  covered  in  DAU 
SPRDE-SE  curriculum; 
however,  there  are  SSC 
Atlantic  unique  review 
types  as  well 

Activity 

17.0  CONFIGURATION 

MANAGEMENT 

Knowledge  and  basic  ability  to  perform 
configuration  management  activities 

Entry 

DAU 

knowledge  can  come  from 
DAU,  but  ability  through  in- 
house  /OJT 

Activity 

17.0  CONFIGURATION 

MANAGEMENT 

Aware  of  configuration  change  control 

Entry 

DAU 

well  covered  in  DAU 

SPRDE-SE 
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Compete 

ncy 

Vector 

Competency  Area 

KSA 

Stage 

Recom¬ 

mended 

Method 

Justification  /  Comments 

Activity 

18.0  REQUIREMENTS 

MANAGEMENT 

Participate  in  (for  a  subsystem  or  simple 
project)  documenting  requirements  in  the 
proper  format. 

Intermediate 

in- 

house 

unique  to  SSC  Atlantic 
requirements 
documentation  approach 

Activity 

18.0  REQUIREMENTS 
MANAGEMENT 

Knowledge  of  the  Engineering  Change 

Proposal  (ECP)  review  process 

Entry 

in- 

house 

unique  to  SSC  Atlantic  ECR 
approach 

Activity 

18.0  REQUIREMENTS 
MANAGEMENT 

Knowledge  of  requirements  management 
process. 

Entry 

DAU 

well  covered  in  DAU 

SPRDE-SE 

Activity 

19.0  RISK  MANAGEME 

NT 

Knowledge  of  and  the  ability  to  contribute  to 
identification  of  risk,  risk  analysis,  and  risk 
monitoring 

Entry 

DAU 

risk  mgt  well  covered  in 

DAU  SPRDE-SE 

Activity 

19.0  RISK  MANAGEME 

NT 

Assists  in  executing  the  risk  mitigation  plan  to 
ensure  successful  project  and  program 
completion. 

Entry 

OJT 

experiential  developmental 
activities  required 

Activity 

20.0  TECHNICAL  DATA 

Ability  to  document  and  present  lessons 
learned 

Entry 

OJT 

experiential  developmental 
activities  required 

Activity 

21.0  INTERFACE  MAN 

AGEMENT 

Understands  the  need  for  interface 
management  and  its  impact  on  the  integrity  of 
the  system  solution 

Entry 

DAU 

well  covered  in  DAU 

SPRDE-SE 

Activity 

22.0  SOFTWARE 

ENGINEERING 

Basic  understanding  of  software  engineering 
principles 

Entry 

DAU 

well  covered  in  DAU 

SPRDE-SE 

Activity 

23.0  ACQUISITION 

Ability  to  develop  a  Performance  Work 
Statement  (PWS)  /  Statement  of  Objectives 
(SOO) 

Intermediate 

in- 

house 

unique  to  SSC  Atlantic 
PWS/SOO  standards 
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Compete 

ncy 

Vector 

Competency  Area 

KSA 

Stage 

Recom¬ 

mended 

Method 

Justification  /  Comments 

Activity 

23.0  ACQUISITION 

Provides  information  for  the  Performance 

Work  Statement  (PWS)  /  Statement  of 
Objectives  (SOO) 

Entry 

OJT 

experiential  developmental 
activities  required 

Activity 

25.0  SYSTEM  OF  SYSTE 

MS 

Understands  that  SoS  capability  needs  impact 
the  system  development 

Entry 

OJT 

experiential  developmental 
activities  required 

Activity 

30.0  SYSTEMS 

THINKING 

Able  to  describe  the  systems  engineering 
lifecycle  processes  that  are  in  place  on  their 
program 

Intermediate 

DAU 

well  covered  in  DAU 

SPRDE-SE 

Activity 

30.0  SYSTEMS 

THINKING 

Able  to  define  system  boundaries  and  external 
interfaces 

Intermediate 

OJT 

experiential  developmental 
activities  required 

Activity 

30.0  SYSTEMS 

THINKING 

Aware  of  the  influence  the  system  has  on  the 
enterprise 

Entry 

OJT 

experiential  developmental 
activities  required 

Activity 

Data  Engineering 

Awareness  of  data  management  and  data 
storage  concepts 

Entry 

external 

vendor 

training  classes  exist,  but 
outside  of  SPRDE-SE 

Activity 

Enterprise 

Architecture 

Knowledge  and  understanding  of  the  purpose 
and  value  of  using  architectures  for 
requirements  documentation;  systems 
planning  and  investment  decisions 

Entry 

in- 

house 

not  well  stressed  in  SPRDE- 

SE 

Activity 

Enterprise 

Architecture 

Knowledge  of  DoD  enterprise  architecture 
principles  and  reference  models 

Intermediate 

in- 

house 

could  also  leverage  SE 
degree/cert 
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Compete 

ncy 

Vector 

Competency  Area 

KSA 

Stage 

Recom¬ 

mended 

Method 

Justification  /  Comments 

Technolo 

gy 

Communications 

Basic  knowledge  of  the  characteristics  of 
different  communications  systems 

Entry 

in- 

house 

could  also  leverage 
external  vendor 

Technolo 

gy 

IT  SERVICE 

MANAGEMENT 

Awareness  DoD  and  DON  ITSM  policies, 
guidance  and  core  references 

Entry 

in- 

house 

SSC  Atlantic  maintains 
basic  ITSM  training 
capability 

Technolo 

gy 

Networks 

Knowledge  of  computer  networking 
fundamentals 

Entry 

degree/ 

cert 

could  also  leverage 
external  vendor 

Mission 

GENERAL 

Basic  understanding  of  all  Mission  Areas  / 
Domains 

Entry 

in- 

house 

could  also  leverage  SE 
degree/cert  for  more  in- 
depth  knowledge 

Core  to  Systems  Engineer 

Activity 

1.0  TECHNICAL  BASIS  FOR  COST 

Ability  to  contribute  to  a 

Project  Management  Plan 
(PMP) 

Intermediate 

in-house 

Would  show  how  a 

SE  contributes  to  a 

PMP  at  SSC  Atlantic 

Activity 

1.0  TECHNICAL  BASIS  FOR  COST 

Ability  to  Review  and  approve 
cost  estimates  for  subsystem 
elements. 

Intermediate 

OJT 

experiential 
developmental 
activities  required 

Activity 

5.0  REQUIREMENTS  ANALYSIS 

Understands  the  characteristics 
of  quality  requirements 

Intermediate 

DAU 

well  covered  in 

SPRDE-SE 

Activity 

5.0  REQUIREMENTS  ANALYSIS 

Prioritizes  requirements  for 
system  upgrades  and  future 
enhancements  with  the 
sponsor/customers,  key 

Advanced 

OJT 

experiential 
developmental 
activities  required 
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Compete 

ncy 

Vector  Competency  Area  KSA 

Stage 

Recom¬ 

mended 

Method  Justification  /  Comments 

stakeholders,  and  end  users 

Activity 

6.0  ARCHITECTURE  DESIGN 

Facilitates  agreements  among 
multiple  stakeholders  to  resolve 
system  interfaces  and 
interoperability  concerns. 

expert 

OJT 

experiential 
developmental 
activities  required 

Activity 

16.0  TECHNICAL  ASSESSMENT 

Executes  continuous  process 
improvements  that  enhance 
processes,  products,  and 
service  quality. 

Intermediate 

in-house 

In-house  CPI 
training  capability 
exists 

Activity 

17.0  CONFIGURATION  MANAGEMENT 

Basic  ability  to  use 
configuration  management 
tools  for  configuration 
management 

Entry 

in-house 

unique  to  SSC 
Atlantic-specific 

CM  tool(s) 

Activity 

19.0  RISK  MANAGEMENT 

Knowledge  of  and  the  ability 
to  contribute  to  development 
of  risk  mitigation/contingency 
action  plans 

Entry 

in-house 

Must  know  how  to 
do  risk  mgt  IAW 
command 
policy/tool 

Activity 

19.0  RISK  MANAGEMENT 

Able  to  perform  risk  analysis 

Intermediate 

DAU 

well  covered  in 

SPRDE-SE 

Activity 

23.0  ACQUISITION 

Serve  on  Source  Evaluation 
Board (SEB)  or  as  a 

Contracting  Officer's 
Representative  (COR)  and 
have  experience  with 
development  and 
implementation  of  contracts, 
procurement  of  major 
hardware  or  software 

Intermediate 

OJT 

experiential 
developmental 
activities  required 
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Compete 

ncy 

Vector  Competency  Area 


Recom¬ 

mended 

Method  Justification  /  Comments 


KSA  Stage 


unique  to  SSC 

Able  to  define  technical 

Atlantic  technical 

Activity 

30.0  SYSTEMS  THINKING 

problem  scope 

Intermediate 

in-house 

scoping  use  cases 

Table  17.  Recommended  Development  Method  for  Each  Systems  Engineer  KSA 


108 


LIST  OF  REFERENCES 


Bloom  B.  S.  (1956).  Taxonomy  of  educational  objectives  handbook  I:  The  cognitive 
domain.  New  York:  David  McKay  Co  Inc. 

Bloom  B.  S.  (n.d.).  Bloom’s  taxonomy  of  learning  domains. 

http://www.nwlink.com/~donclark/hrd/bloom.html.  Accessed  July  20,  2013. 

Chestnut,  H.  (1967).  Systems  engineering  methods.  New  York:  Wiley. 

Checkland,  P.  (1993).  Systems  thinking,  systems  practice.  New  York:  John  Wiley  & 

Sons. 

Daintith,  J.  (2009).  A  dictionary  of  physics.  Oxford:  Oxford  University  Press. 

Defense  Acquisition  University.  (2012,  October).  Chapter  1.4  Defense  Acquisition 
System.  In  Defense  Acquisition  Guidebook. 

https://acc.dau.mil/CommunityBrowser.aspx?id=488292.  Accessed  July  26,  2013. 

Flagle,  C.,  Huggins,  W.,  &  Roy,  R.  (1960).  Operations  research  and  systems 
engineering.  Baltimore,  MD:  Johns  Hopkins  Press. 

Gelosh,  D.  (2009).  What  defines  a  systems  engineer?  Comparing  and  contrasting  global 
perspectives  on  systems  engineering  competency.  INCOSE  Insight,  12(3),  2009: 
34. 

Holt,  J.  &  Perry,  S.  A.  (201 1).  A  pragmatic  guide  to  competency.  Swindon,  UK:  British 
Informatics  Society. 

Institute  of  Electrical  and  Electronics  Engineers.  (1998).  IEEE  Standard  1220: 

Application  and  management  of  the  systems  engineering  process.  New  York: 
author. 

International  Council  on  Systems  Engineering.  (2004).  INCOSE  systems  engineering 
handbook.  Seattle,  WA:  author. 

International  Council  on  Systems  Engineering.  (2010).  Systems  engineering  competencies 
framework  2010-0205.  San  Diego,  CA:  author. 

Jahangir,  E.  (2012,  July).  A  framework  to  institutionalize  systems  engineering  skill-set. 
22nd  Annual  INCOSE  International  Symposium,  Rome,  Italy. 

Krishnan,  G.  (2008,  February).  Education  versus  training.  Simply  speaking:  on  learning, 
business  and  beyond.  http://simplv-speaking.blogspot.com/2008/Q2/education- 
versus-training.html.  Accessed  July  8,  2013. 


109 


National  Initiative  for  Cybersecurity  Education.  (2012).  National  cybersecurity  workforce 
framework,  http://csrc.nist.gov/nice/framework/.  Accessed  8  July  2013. 

National  Aeronautics  and  Space  Administration.  (2012).  Project  management  and 
systems  engineering  competency  framework  v3.0.  Washington,  DC:  author. 

Parker,  S.  (Ed.).  (1994).  McGraw-Hill  dictionary  of  engineering.  New  York:  McGraw- 
Hill. 

Pyster,  A.,  dwell,  D.,  Hutchison,  N.,  Enck,  S.,  Anthony,  J.,  Henry,  D.,&  Squires,  A. 
(2012).  Guide  to  the  systems  engineering  body  of  knowledge  (SEBoK)  version 
1.0.1.  Hoboken,  NJ:  The  Trustees  of  the  Stevens  Institute  of  Technology. 

Pyster,  A.,  Olwell,  D.,  Ferris,  T.,  Hutchison,  N.,  Enck,  S.,  Anthony,  J.,  Henry,  D.,  & 
Squires,  A.  (2012).  Graduate  reference  curriculum  for  systems  engineering 
(GRCSE™).  Hoboken,  NJ:  The  Trustees  of  the  Stevens  Institute  of  Technology. 
www.bkcase.org/grcse/. 

Systems  planning,  research,  development  &  engineering — Systems  engineering/program 
systems  engineering  competency  model.  (2009).  https://acc.dau.mil/adl/en- 
US/406181/file/54341/Competency%20Model.pdf.  Accessed  May  30,  2013. 

Squires,  A.,  Wade,  J.,  Dominick,  P.,  &  Gelosh,  D.  (2011).  Building  a  competency 

taxonomy  to  guide  experience  acceleration  of  lead  program  systems  engineers. 
Ninth  Annual  Conference  on  Systems  Engineering  Research,  Redondo  Beach, 

CA. 

Space  and  Naval  Warfare  Command.  (2013).  SPAWAR  systems  engineering  guidebook 
process  framework.  https://sseg- 

dev.  spawar.navv.mil/ se  landing/home. i  sp?tabindex=  1  &index=search.  Accessed 
July  26,  2013. 


110 


INITIAL  DISTRIBUTION  LIST 


1.  Defense  Technical  Information  Center 
Ft.  Belvoir,  Virginia 
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